[Development] Future of Qt on Web?

[Jason H]

While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below).

Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt?

As for the various approaches over time,
Wt, (2005): I believe that Wt has it pretty close to right*, where the architecture leverages balanced mix of server and client code
QMLWeb (2014): Re-implmenentation of QML in browser, including QML parser.  
Qt 5.10 WebGL (2017?): server issue low-level draw commands

It strikes me that the proper* balance would be server-side implementation is light-weight and leans on the client for rendering.
In a way, I consider all web frameworks as failed as there is a new one every 3 months. I think the problem comes from treating the web as a platform and not merely a delivery platform. It can't be a platform because it requires a server in a completely different architecture than the client. The client is continually being changed, which means your application code has to be changed to take advantage of those features. This is what Wt gets right: it is a library and you can target new browser features (i.e. websockets) with just relinking to a new library version. There is no application-specific code that has to change. This turns the web into a delivery platform, as how I think it should be treated (aka "proper", imho)

The "proper" balance would then be a server-side widget/QML element hierarchy which is synchronized with the browser. The browser uses it's own logic intelligently update. It would seem to me that the next step is to take the WebGL stuff and iterate it to the point that it's not the GL commands being sent, but higher level logic that relies on the browser to issue those commands to itself. Of course a QWidget::paint() call gets complicated, but maybe the compilation output could be a WebAssembly function that is sent to the client. In this approach there's isn't a complete version of Qt for WebAssembly, just the application-specific code that the browser needs to know about. 

Thoughts?