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?




_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to