I (actually not only me but also a few other guys) wrote an open source GUI dictionary for Linux [1] (it uses Qt selection features that don't work the same way

I (actually not only me but also a few other guys) wrote an open source GUI dictionary for Linux [1] (it uses Qt selection features that don't work the same way on other platforms, so although it compiles on, say, Mac, it doesn't fully work). It was started with Qt4 10 years ago, then it was ported to Qt5. So I think I can share my perception of Qt. The framework is very solid, the components are easy to combine and in general, once you get used to it, it becomes quite easy to work with them. The resulting app is very performant and has low memory consumption in comparison to JS-based apps. Also, adding asynchronicity is actually not hard, at least for things like HTTP requests, as you can use Qt signal/slot system to receive events asynchronously so that in simple cases it is not necessary to mess up with threads. However, the developer productivity is, in my perception, is a somewhat less than with modern JS frameworks. Not 10x less, but a bit less. I think one of the issues is C++ itself: after changes in the code, it is necessary to not only rebuild but rerun the app, and in general writing C++ code is something that requires some attention as otherwise, it is possible to have SEGFAULT somewhere in your app and then spend time looking for the place in your new code that causes this SEGFAULT. Note that I'm talking here only about classical QtWidget/C++ apps, not QtQuick ones. I think productivity with the second ones should be better. However, one might argue that if you started to write your code in Javascript, it's better to do it in a way that allows you to have the same code running natively in browser (QtQuick experimentally runs in it, but it is experimental and not mainstream), so that you can share components and code for example between your site and your desktop app. [1] http://qstardict.ylsoftware.com http://qstardict.ylsoftware.com