> On 3 Jan 2017, at 15:07, Ulf Hermann <ulf.herm...@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… _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
