[Interest] 2017

[Shawn Rutledge]

> On 3 Jan 2017, at 15:07, Ulf Hermann <ulf.hermann at qt.io> wrote:
>> Another alternative of course is to use some other client-server protocol such that only the “model” of MVC is on the server, and UI rendering instructions are sent across the network instead of actual rendered graphics.  For example load QML over the network and run it locally.  For some reason we aren’t putting much emphasis on that as a primary use case yet, but I wonder if anybody in the field is doing much of that?
> 
> It's called "The Web" and there are many reasons to hate it. However, one thing the relevant people in the field got somewhat right (IMO) is the level of coupling between the "model" and the rest of the application.

It’s just that QML rendering is more efficient than any browser… that’s what we keep telling people anyway.  ;-)  So I think we need to focus a bit on QML-based web applications at some point.  If you use http to load the QML (which we have already been able to do for years) then you’ve got the same model / view&controller separation that the web has, and can easily rewrite the front-end without changing whatever REST services (preferably) that it depends on.  Even since the late 90’s or so, people have been saying that it makes more sense to write new applications with HTML rather than widgets; so if we leave ourselves out of that, well...

BTW now that https://codereview.qt-project.org/#/c/181098/ is integrated, it so happens that you can use the qml runtime as a “browser” for qml files on a web server.  As in

qml http://ecloud.org/expt/qtquick/multiparticles.qml

(And that wasn’t even the point of that patch.)  Hmm, seems that it still needs work to be able to load dependencies beyond that first qml file though…