The problem here is probably more download time, not run performance.
The mechanisms are still there but the practice died when Qt stopped focusing on embedded targets.
http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-pr...
Embedded is the biggest market for Qt right now.
1) Qt Widgets development stopped with 5.0. I had bugs filed on the embedded Linux targets and was told "sorry, these will never be fixed".
2) #1 means that Qt wants you to use QML. I need to run a Javascript engine on my target? Note in the comments of that blog post that they hope to run on an A7 (or really fast M7)...someday.
2b) ...And if they do run on a lower end platform, you still need a POSIX O/S. uCLinux is not a great option on M3/M4 CPUs and keeping the binding dynamic on those cores to stay LGPL compliant is extremely difficult.
3) QML bindings are a pain in the ass, especially when you're trying to put a UI on legacy code.
4) Most crucial: Qt Lite and QtDC are commercial products only.
So, in my opinion, embedded is still a 2nd class player. Or, I could clarify further: low end embedded is a 2nd class player. If you're working on automotive HMI/IVI? They'd love your business.
I've shipped a dozen products with it over the course of my career.
On embedded targets I'd never use anything else. The alternatives are way too simple or overscripted playback engines that have no flexibility with underlying code.
http://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/
> So, quite many new things for Qt Quick users, but not to worry – we have not forgotten users of Qt Widgets. On the contrary, already during the past year we have been increasingly addressing open bugs of Qt Widgets and intend to continue doing so during 2018 and beyond. Both Widgets and Qt Quick have their strong points and they complement each other nicely as fully supported parts of the Qt offering.
Web-apps are architected fundamentally different than classical software.
#include <QLabel>
#include <QApplication>
int main(int argc, char** argv)
{
QApplication app{argc, argv};
QLabel label{"hello world!"};
label.show();
return app.exec();
}
$ g++ -O2 -g0 -fPIC hello.cpp -I/usr/include/qt -I/usr/include/qt/QtWidgets -lQt5Widgets -lQt5Core
$ du -csh a.out
16K a.out
So nice to see people fabricating numbers and passing them off as data.
That's not why these demos "Hello Framework" demos are 3-7MB though. That's due to the cost of shipping an entire widget system that takes complete responsibility for everything between raw user input to pixels on the screen, without using many of the affordances of browser APIs. This is really awesome for emulation, sandboxing, and preservation of software, but it's not a good route for saving bytes for the user.