3 ms·
>With every browser implementing its own subset, in its own way, with its own quirks, the requirement to create documents that look and behave consistently acro
by AgentME 9y ago
>With every browser implementing its own subset, in its own way, with its own quirks, the requirement to create documents that look and behave consistently across browsers and platforms quickly becomes untenable.
Adding a new thing for all browsers to implement and slowly become consistent on just as CSS is maturing into something great with flexbox and grid support in more browsers doesn't seem to be addressing the quoted problem. ... I assume the author's idea wasn't just that browsers should all adopt Qt's implementation and stick to that one implementation.
If people want QML in webpages, surely that could be implemented on top of JS+HTML+CSS like a web framework. If it as a web framework is shown to work very well for developers and fit the web ecosystem but has some practical issues like performance, then that would be good fuel to motivate browser developers and standards groups to standardize webpages based on QML. If it as a web framework works well and doesn't have intractable performance issues, then ... it could stay as a web framework and become popular if it really does work well for developers. Why saddle browsers with the responsibility to implement more than they need to if HTML+CSS+JS provides a good base for other paradigms to be implemented on top of?
- martin_ky 9y agoYes, I (post author) believe QML can be implemented on top of current browser tech, namely JS+DOM, or NaCl+WebGL. Someone indeed did implement a subset this way - https://qmlweb.github.io/ https://qmlweb.github.io/ and the latter might even be supported by Qt Company - http://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-emscripten/ http://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-e... although I didn't try that myself and I don't know if that effort is still ongoing. I'm not a fan of stacking too many abstractions on top of each other. QML basically consists of the same ingredients as other web tech: a javascript runtime + GL/ES renderer + network access manager = same things a HTML5 engine needs under the hood. Surely these could be reused in a browser implementing QML.
- vesinisa 9y agoJust a little nitpick, (P)NaCl is not a current web tech as it's being deprecated by WebAssembly. https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...
- martin_ky 9y agoYou're right. The blog post announcing the NaCl port is dated 9/2015. I don't believe that effort is still active nor am I aware of any official efforts to get Qt / QML run on WebAssembly. There is the Qt Quick WebGL Streaming official project - https://news.ycombinator.com/item?id=13744631 https://news.ycombinator.com/item?id=13744631 - but this is a different thing entirely: instead of running the QML app on the client, the app runs natively on the server. Instead of rendering the UI directly using OpenGL, the scenegraph generates a stream of WebGL commands. An accompanying JavaScript library receives this command stream through a web socket an replays it in the browser on a WebGL canvas. Kind of like what Remote Desktop does.