Can QML become the next standard for web UI?

[AgentME]

>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]

Yes, 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/ and the latter might even be supported by Qt Company - 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.

[ahmedfromtunis]

Am I the only one who expected at least some code examples?

Also:

> Building for HTML5 is free. There are some non-essential paid tools that can help. Qt requires a commercial license for most commercial use on mobile.

Source: https://www.developereconomics.com/cross-platform-apps-qt-vs...

[ncr100]

https://qmlweb.github.io/ (early) demonstrates QML in a browser.

https://github.com/qmlweb/qmlweb/projects/1 shows how much is yet to be done.

[virgil_disgr4ce]

I expected a lot more. I found this: http://doc.qt.io/qt-5/qmlfirststeps.html

[martin_ky]

I apologize. I wrote the article expecting that readers would be already familiar with QML or look it up.

What I ultimately wanted, was to get a discussion going and see if other people (who know both QML and HTML) share my view - that QML would be a great alternative (not replacement) to HTML for writing web UIs.

[imhoguy]

Yet another declarative UI language. Anybody remembers Mozilla's XUL [1]. It was even available for the Internet web sites for a moment.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL

[PaulHoule]

XUL, XAML (Microsoft .net), FXML (Java FX), ...

[flavio81]

Anything that liberates me from the current state of matters is welcome. The current state of matters is:

    use CSS preprocessor to generate CSS
    use framework (i.e. React) to transformate pseudo-HTML component model to HTML5 at runtime
    use a tool like Babel to transform your-favorite-pseudo-JS (i.e. Typescript) to the JS-supported-by-the-users-browser-at-that-session

... all of this only for making alive a GUI.

Seriously, it is like a sick joke. HTML was never designed for declatatively describing an UI and we have had to kludge it for the last 15 or 20 years. First, with forms and input tags and postbacks, then with AJAX, now with S.P.A. tools. It's still a heap of kludges.

The sooner we can have a good,state of the art, portable, declatative UI language, the better.

[majewsky]

> all of this only for making alive a GUI.

All of this for making alive a GUI using the 2017-summer-season toolchain. Meanwhile, plain HTML with <form> elements and server-side processing miraculously continues to work.

[zerkten]

I'm not sure that any of these UI frameworks are going to get much traction, simply because they aren't as flexible, and don't solve web problems as well as the existing solutions. A search turned up https://github.com/qmlweb/qmlweb, but running QML from JS doesn't seem like the author's vision, or something that would be appealing to many developers.

How is QML different from XAML? XAML isn't purely a UI markup format, but it doesn't seem to have gotten traction with the web development community. Someone has created http://www.cshtml5.com/, but it's not something I've seen developers talk about within the .NET community (the most likely people to adopt XAML, if it became available for the web.)

[martin_ky]

> I'm not sure that any of these UI frameworks are going to get much traction

QML / Qt Quick gets a lot of traction, from mobile and embedded systems developers and lately a lot from automotive industry. It's just largely unknown to web developers, because it's not on that platform. What I would like to see, is that it got noticed from web developers too and then maybe it will get some push to get to the web.

> they aren't as flexible, don't solve web problems as well as the existing solutions

IMO, it's the current web technology that creates those "web problems" :) I don't say that QML solves them all. But it couldn't hurt if we have an alternative to HTML+CSS.

[goalieca]

Xaml is the least pleasurable framework I've ever used. I have two reasons: MVVM seems like an anti-pattern and the .Net API is builds on is too complicated.

I went from a project using xaml requiring massive system resources to another built in qt running speedily on an intel atom. I wasn't too familiar with either frameworks when I started. Qt was also way easier to maintain despite being built on top of c++ template magic

[jcelerier]

> How is QML different from XAML?

QML is a declarative & reactive programming language, while XAML (and FXML mentioned earlier) are only for markup.

You can't do this in pure XAML:

  Item { 
    x: 5
    y: x + 2
    Timer { 
      onTriggered: x = x+1; 
      interval: 50 
    }
  }

Here, every 50 milliseconds, x would be updated, and y would be updated automatically accordingly to the new value of x.

[jancsika]

> I'm not sure that any of these UI frameworks are going to get much traction, simply because they aren't as flexible, and don't solve web problems as well as the existing solutions.

That's a great point.

Here's a clarifying question: regardless of the quality of HTML5 standards, does access to inline svg DOM nodes fulfill an important purpose? If you think the answer is yes, then QML cannot replace HTML5 because its primitives are less expressive than SVG paths.

[CarVac]

I would love if QML were to become a web standard, it's a joy to work with in my experience (writing a desktop application).

[gregschlom]

Can second this opinion, and I was using it back in 2011 when it was a brand new experimental thing from Nokia (which at the time owned Qt). My first reaction was "omg I want to be able to use QML on the web"

[martin_ky]

There has been a recurring theme in the comments: "You don't just replace HTML with something else and non standard overnight."

Perhaps, I should clarify... In my blog, I don't call for replacement of any current web technology. I am simply proposing an alternative client language that would exist side-by-side with current tech. Purely from technical perspective I believe QML could be this language, because unlike HTML, it was purpose-designed from the beginning as a UI language.

It does not mean rewriting browsers from scratch either. QML and the Qt Quick library share many aspects and technologies with any HTML browser - a JavaScript core, a web access network stack, utilizing native graphics acceleration APIs. So already there would be many common shared components. In my idea, QML would be just another frontend (language) reusing those components. Although implementing QML on top of current tech (HTML+JS+WebGL) is also within the realm of possibility, it's entirely not what I had in mind and would defeat the purpose.

I also don't want to add any non-standard extensions or plugins to existing browsers. What I would like to see, is QML being adopted as a new web standard. I realize this does not happen overnight and that there are political, commercial, licensing and consensual prerequisites that need to be solved first. It would be interesting to hear the thoughts of Digia and KDAB (the companies behind Qt) on this.

From a technical standpoint, I don't see any obstacles why this could not happen. QML is conceptually a simple language and I think it could be standardized relatively easily. The next step would be to standardize the library of UI elements (Qt Quick) or its minimal viable subset for version 1.

[davidkhess]

I'm a fan of QML and use it regularly to build cross-platform mobile apps – however, how would this fair any better than Flash or Silverlight did?

It seems like there needs to be some strategy for how this would roll out to market and feasibly gather market share before I could take the concept seriously.

[zanny]

The problem with Flash et al is how they were proprietary browser plugins. I do not believe anyone is trying to pursue QML web integration as a plugin, especially since plugins are going away all together in every major browser. I'm not sure if you could webassembly a working environment, but having to redirect users to install an addon is a huge UX failure.

The goal would be strictly to get .qml supported as a render target the same way .html (and in many browsers, .mp4 / .png / .svg / .json etc) is today.

[ericfrederich]

Maybe with WebASM you could ship a QML viewer.

Single code base to create rich Android, iOS and browser app?

[ris]

> 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 also easy to visualize what the scene will look like by reading the source code.

This is not necessarily what is wanted though. You are thinking like a graphic designer and ignoring accessibility, user preferences and genuine client platform considerations (imagine a web app designed before the advent of smartphones which assumes the presence of a mouse). The way the web works is as a negotiation between the developer/designer and what the user's browser is prepared to present to them (based on how it's been configured).

What of being described here is something a lot more like flash. Which is possibly OK for actual native applications.

[drivingmenuts]

Personally, I'm pretty OK with just writing standard HTML, CSS (with Sass), and using JQuery.

React and Angular and their ilk are too abstracted for my tastes. Too much tooling required.

[retox]

>Angular and their ilk are too abstracted for my tastes.

This is my experience learning angular for my latest role.The basic concepts seem easy to grasp but there are so many thing going on "for free" that I can't reason about what is actually happening. I'm hoping it becomes easier with time but the tooling is making things harder than it needs to be.

[floatboth]

jQuery is not very useful these days though. It just provides imperative functions for doing stuff — manipulating DOM elements, making HTTP requests and so on — and they're no longer necessary since pretty much everything is built-in now (querySelector, classList, Promises, fetch, Web Animations…)

And what jQuery does not do is the one important thing — declarative data binding.

By the way, another built-in thing in browsers is Web Components — having a component model is also necessary for modern app development. So if you take Web Components and add data binding and some other sugar, you get Polymer. Here's a good overview of each layer of sugar it adds: https://www.youtube.com/watch?v=assSM3rlvZ8

I also don't like React and Angular — but I absolutely enjoy working with Polymer.

[yellowapple]

"It will look and behave identically on all platforms and devices."

I'm not sure if that's a particularly good feature to have. At the very least, the ideal UI for a desktop application will usually be different from that of a mobile application.

By all means make it cross-platform, but there really ought to be mechanisms for adapting to different platforms. HTML+CSS does a reasonably good job of this nowadays.

[martin_ky]

Creating responsive UIs in QML is quite easy: just hook to the screen size property (width property of the root element) and modify your scene accordingly. What I meant by that was, that QML is rather good at displaying things that you meant to look the same identically across platforms.

[jspears]

I think its pretty awesome, Reminds me of Chris Oliver's F3 before Sun ruined it with XML (JavaFX). F3 had awesome demos and was a joy to write - http://lambda-the-ultimate.org/node/1998

[virgil_disgr4ce]

I love the idea of a purely (would it really be, though?) declarative UI paradigm, but this particular post offers very little. What other attempts at declarative UI on the web have been taken, beyond just bits and pieces of an otherwise imperative framework?

[opportune]

Can't tell if this is an especially dry joke or not, but HTML

[moosingin3space]

React/Vuejs components are declarative UI at their core. That idea tends to get lost in the soup that is state management, but it is there.

The easiest-to-integrate React/Vuejs components are very close to purely declarative, in my experience.

[ezioamf]

Looks very similar to NCL https://github.com/PayWithMyBank/ncl but not having a easy way to create rules to override previous definitions.

[zanny]

QML is not meant to be a styling language. Its for writing applications. It replaces all of html / css / js. You declare your objects, style them, and have code run in them all in the same place.

It behaves like a widget-based programming language toolkit, so you would have global style properties with per-item optional overrides.

[ryanmarsh]

With HTML 5, visual consistency could be achieved more easily: instead of manipulating the DOM, we can write our own presentation code using the canvas element

First we'll start by breaking the browser and everything that integrates with it.

FTFY

[groby_b]

Then we'll promptly forget about a11y.

There are many shortcomings to HTML, yes. "Just replace it" is not the right answer. It has never been, for the same reasons that you don't "just rewrite" an old code base. There's more value than the naked eye can see.

(Oddly, the web has just the example for that - Netscape 6.0. That was a from-scratch-rewrite, and oh my, was it painful)

[jcranmer]

I mean, it's not like the DOM does anything useful, like let blind people navigate a website.

[yellowapple]

And then we'll reimplement it.

Poorly.

[adrianlmm]

A propietary format? I don't think so.

[FRex]

It's very far from a proprietary format. Qt itself is available under GPL/LGPL and a special commercial closed license for those wishing to write proprietary programs, QML is not patent protected and KDE has a special deal in place to ensure Qt won't ever be made unfree: https://www.kde.org/community/whatiskde/kdefreeqtfoundation....

[clishem]

Betteridge's law is strong with this one.

[mrkrabo]

Nobody remembers Wt. :(

[majewsky]

I have a friend who is building a new Wt application just now, and he's very satisfied with it. (Just intranet, though, so I cannot share any links.)

[prewett]

Care to elaborate what it is, its relevance to the discussion, its presumably better features, etc.?