Can QML become the next standard for web UI?

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,
• performance,
• 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,
• JavaScript code for imperative programming.

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.

Resources:

1. https://www.developereconomics.com/cross-platform-apps-qt-vs-html5
2. https://v-play.net/competitor-comparisons/qt-vs-html5-cross-platform-apps
3. http://blog.qt.io/blog/2017/07/28/qml-vs-html5/

Discussion:

1. https://news.ycombinator.com/item?id=14894937