Similar idea as X Window client/server protocol (circa 1984). Similar drawbacks: UI experience is subject to network latency and disruptions. It also means you

Similar idea as X Window client/server protocol (circa 1984). Similar drawbacks: UI experience is subject to network latency and disruptions. It also means you have to run the application on a server, in order to publish it to the web. The "ideal" solution would be to run the entire Qt/C++ application in the browser, as a static "web page." This is can be done using WebGL and cross-compiling C++ to asm.js/WebAssembly. There are several Emscripten demos showing exactly that, with an ancient version of Qt [1]. But I guess the Qt team has decided they don't want to support that direction (i.e. not even trying to port Qt5 to Emscripten, but instead offering this "WebGL streaming" thing)? Although, given how "heavyweight" Qt5 seems to be, I guess cross-compiling the whole thing to WASM would result in something very inefficient. Personally, I have been troubled by Qt's recent direction. First there was the confusion of legacy QWidget vs. modern QML. A modern approach to UI specification is welcome, though I question the need for embedding a JavaScript engine when QML could have been compiled to native code. But the real issue with QML is that the legacy QWidget approach was never really depreciated, so Qt was no longer a coherent, unified approach to developing UIs. Qt5 looks like two completely different UI libraries combined into a confusing whole. The general spirit seems to be that desktop applications are a second-class citizen in Qt, relegated to using legacy QWidget framework, and the new QML framework is targeted towards mobile applications (the new first-class citizen). This is unfortunate because users run most professional applications on desktops with keyboard and mouse input, not on 6-12" touchscreens. More recently, they decided that the whole "Qt Quick Controls" line had terrible performance, so they were going to dump cross-platform "native look & feel" (the original raison d'être of Qt) in favour of a "Qt Quick Controls 2 [2]. Although, more recently, they seemed to be walking back that "native look" decision (making the roadmap even more uncertain) [3]. If the message to desktop developers wasn't clear enough already, the sparse list of "Qt Quick Controls 2" [4] components that have shipped so far are squarely aimed at simple mobile apps ("Drawer," "Switch," "SwipeView," etc) and is missing basic components needed to build a desktop application (for example, no promised release date for shipping a data table view component). It turns out that this enormous edifice that has been built up, on top of Qt's native C++ roots, is incompatible with the future direction that web browsers are taking with WebAssembly and WebGL. While these browser developments are proving to be a great thing for bringing OpenGL native applications to the web browser [5], Qt seems to be left behind. They instead have to resort to building this "WebGL streaming" functionality on top of an already teetering stack, in order to deliver applications through the web in away that has obvious drawbacks. In my opinion, the C++ community should move past the Qt legacy and come up with a new industrial-strength, cross-platform UI library that has simultaneous first-class support for web, desktop, mobile and embedded targets. [1] http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc... [2] https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-new-beginning/ https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-n... [3] https://blog.qt.io/blog/2017/02/06/native-look-feel/ https://blog.qt.io/blog/2017/02/06/native-look-feel/ [4] https://doc.qt.io/qt-5/qtquick-controls2-qmlmodule.html https://doc.qt.io/qt-5/qtquick-controls2-qmlmodule.html [5] https://floooh.github.io/oryol-samples/ https://floooh.github.io/oryol-samples/