6 ms·
I think the points raised are solid, but at this point it seems like Electron is the best worst solution for cross platform UI. Having worked with Qt I never wa
by K0nserv 10y ago
I think the points raised are solid, but at this point it seems like Electron is the best worst solution for cross platform UI. Having worked with Qt I never wanna do that again. There's also a much more significant portion of developers who can work on Electron based apps. Part of picking the best tool for the job involves considering maintainability and ease of development after all.
- santaclaus 10y ago> Having worked with Qt I never wanna do that again. I've had to work on PyQt5 at work, and was pleasantly surprised out how easy it was to hack up a full app.
- witty_username 10y agoWhat are your problems with Qt? I was using PyQt, and I found it nice (Qt's integration is good).
- K0nserv 10y agoI was using C++ Qt. Just found it really unintuitive and difficult to use compared to web technologies and native macOS development.
- witty_username 10y agoCould you give an example of something that was unintuitive or difficult to use?
- freeone3000 10y agoC++ Qt, I've found, is an entire separate beast. It goes out of its way to not rely on the STL, so that std::string and QString are separate, non-convertible classes. QList and std::list<> are the same, same for QMap and so on and so forth. So data communication is already a pain. We then have further issues with function invocation. Slots and sockets are simple with python, because functions are first-class in python. In C++, they are very much not, so slot-socket binding looks like: connect(sender, SIGNAL (valueChanged(QString,QString)), receiver, SLOT (updateValue(QString)) ); This is less than ideal.
- pjmlp 10y agoWhen having to deal with compilers that barely support a mix of C++98 and C++03, Qt is quite good. STL wasn't always here and still isn't in some embedded platforms.