We use Qt heavily at Starsky Robotics. We initially used it because it has tight integration with ROS via RQT [1], but I'm pretty impressed with the framework in general. Lots of great tools out of the box, QtCreator is awesome and once you get the right signal/slot model in your head everything is a breeze. Plus getting to prototyping in python is always fast!
For our use case, relative speed of the GUI isn't a factor. We've considered moving to electron just for ease of development, but python is winning out.
I can't comment for pyQt. But the regular C++ Qt app I'm tinkering with at the moment uses 11MB private and about 50MB in shared memory for displaying a simple window with some nested widgets and scrollable lists.
for reference, the app I'm working on (https://ossia.io), a
multiple-hundred-LOC Qt-based DAW with support for many network protocols and which uses most Qt libraries as well as boost uses itself 41 megabytes of RAM (private working set) and 70 megabytes total (working set) with a small document loaded, according to the windows task manager.
I don't know off hand, and we never compared w/ Electron, it was just floated as an idea. When we eventually fully refactor our GUI code to be agnostic of ROS we'll profile more completely.
I'm presenting QGIS-ROS at ROSCon this year. It's a QGIS plugin for integrating real time robot data. Was relatively easy to do thanks to QGIS being Qt 5.
All of our end users are internal, so the main bloat-related problems wouldn't really be an issue at all. Why should we be worried about electron in the future?
> even though the development time is obviously shorter with electron
Evidence? I think you're making a great point (about the reputation of html/css/js) but leave the unfounded claims out and your point would be stronger.
For our use case, relative speed of the GUI isn't a factor. We've considered moving to electron just for ease of development, but python is winning out.
[1] http://wiki.ros.org/rqt