Recently, I came across a few articles [1, 2, 3] comparing Qt’s modern UI framework – Qt Quick and its own declarative language QML to HTML, with QML coming out as a clear winner in several categories:
- speed of learning,
- ease of use,
- cross-platform compatibility.
Although QML is not a substitute for HTML – they were designed with different goals in mind – I think QML would make a great web technology.
No matter which client framework is currently in fashion, building an UI on top of HTML is using the wrong abstraction for the wrong purpose. HTML was originally created as hyper-text markup language. Its primary function is to semantically structure and link text documents. Presentation was largely left to the user agent (browser). The user could even configure certain aspects like fonts or colors. Over time, more presentation control mechanisms were added. Today’s HTML, CSS, DOM and JS scripting is a weird mix of text markup, presentation and behavior. 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.
With HTML 5, presentation consistency could be achieved more easily: instead of manipulating the DOM, we can write our own presentation code using Canvas and its imperative graphics API. We can go even more low-level with WebGL. In this case, HTML is not really in use anymore – it serves only as a container in which the Canvas element is embedded. Whether we write our own rendering code or use a Canvas based library, it’s hard to get it right. More often than not, Canvas-heavy websites generate excessively high CPU load.
In contrast, QML was designed from the ground up for modern, fluid, data-driven UIs. At its core is a declarative component-based language with dynamic data bindings and powerful animation and state management system. The language is complemented by a comprehensive library of UI primitves, called Qt Quick, with well defined properties and behaviors. A QML document describes a tree of visual (and non-visual) elements that form a scene. With data bindings being a core concept, the separation of data from presentation is trivial and encouraged. The scene is controlled by any combination of the following mechanisms:
- a data model hooked into the scene using data bindings,
- reactions to events from user input, sensors, location and other APIs,
A QML document defines a scene completely and precisely. You can think of it as pure presentation. Nothing is left to interpretation for the runtime. It will look and behave identically on all platforms and devices. Due to the declarative nature of the language, it is easy to imagine what the scene will look like by reading the source code.
Under the hood, QML uses a scenegraph engine implemented on top of whatever low level graphics API is available on the platform: currently OpenGL and OpenGL ES on embedded platforms, with Vulkan and D3D12 backends in the works. The engine uses modern programmable graphics hardware and is heavily optimized and CPU efficient, only redrawing the scene when needed.
It is obvious that QML and Qt Quick would be a great fit for the web. I wish browsers already supported it as standard. The big question is: what is the chance of big browsers implementing QML? Unlike HTML, which is an open standard, QML (although open-source) is a proprietary technology owned and developed by the The Qt Company. It would probably have to be developed into an open standard and in partnership with major browser vendors. I don’t know if this is going to happen anytime soon, or ever. Realizing they are missing out on the biggest platform – the world wide web – The Qt Company might want to invest in this direction. It would be a win for everybody and most certainly web developers.
Update (6/2018): It looks like Qt is going to support the WebAssembly platform, so QML in your browser might be a reality soon. Sure there are rough edges right now and the performance is not great either. Let’s see where this goes.
Pingback: New top story on Hacker News: Can QML become the next standard for web UI? – The Internet Yard
Maybe I’ve only done to little ‘actual UI’ in HTML/CSS (and more ‘styled documents’ like CSS is intended for), but in my experience the difficulty is more in expressing the layout constraints into CSS boxes (especially if you care about keeping your markup halfway semantic) than cross-browser consistency. But I would be down with a ‘QML stylesheet’ that transforms an HTML document into a QML scene.
Pingback: Can QML become the next standard for web UI? | ExtendTree
Well, not exactly… I want a 15th standard right there in the first box of that strip :)
Pingback: QML vs HTML5 – PipisCrew Official Homepage
One of Seif’s (http://seif.place/) innovations is to use QML in the browser (others include a replacement for SSL, replacing DNS, some appealing cryptographic primitives, and standardizing on JSON as the data format between client and server).