>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?
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.
You'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 - 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.
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.
I love that the syntax doesn't require commas at the end of field assignments to be honest. Anything that lets you copy/cut and paste lines around without having to jump the cursor somewhere after to add things like commas or braces to avoid annoying syntax errors is great. I like significant whitespace languages like Python for the same reason and syntax like OCaml's where you omit brackets for function calls.
My opinion is that QML not going to supersede web tech any time soon. As broken as CSS is, it is here to stay for the a while yet. The tooling for QML isn't great. You're heavily relying on QT Creator etc and the licensing around all that stuff. The exact opposite of FOSS that the web embraces.
Also FWIW, I know it's a holy issue but when you copy lines round in python etc you ARE having to add and remove those extra bits of syntax except they're invisible, they're spaces/tabs (don't even). Any sane person would have to have white space visibility turned on in their editor so would just be looking at cruft anyways.
Sticking on the topic of syntax, JSON has its own annoyance that the extra comma on the last field will be a syntax error when other languages let you get away with it. A field that goes over two lines is the exception so there should be a more verbose syntax for that rather than for single line fields in my opinion.
> As broken as CSS is, it is here to stay for the a while yet.
I prefer SASS with significant whitespace, no semicolons and no braces. :P
> Also FWIW, I know it's a holy issue but when you copy lines round in python etc you ARE having to add and remove those extra bits of syntax except they're invisible, they're spaces/tabs (don't even). Any sane person would have to have white space visibility turned on in their editor so would just be looking at cruft anyways.
Hmm, so in pretty much all IDEs, I can paste Python code then do TAB or shift+TAB to fix the indentation level as what you pasted is still selected. Having to add e.g. curly braces/bracket to fix nesting is miles more cumbersome and error-prone when there's a syntax error. It's super irritating trying to work out where the missing brace/bracket is.
I'm less concerned how it looks and more concerned how easy it is to move lines of code around plus find syntax errors. I'm still amazed how bad syntax error messages are at helping you work out what's wrong.
> JSON has its own annoyance that the extra comma on the last field will be a syntax error when other languages let you get away with it.
My thoughts exactly. I am repeatedly astounded by the fact that McCarthy thought of something abstract as Lisp syntax in the 50s and yet it did take ages for Algol-derived languages to figure out the comma thing.
The case of JSON especially irritates me since its not only supposed to be easy to parse (and - honestly - allowing an additional comma wouldn't be hard anyway), but easy to generate as well...
Also: You know something's wrong when all your SQL templates look like
The "Algebraic Manipulation of Symbolic Expressions" was basically predecessor to S-exps, but with commas.
The interesting thing is that math notation has some comma-based things (function arguments, sets, sequences) and some that don't use commas (like matrices and vectors).
> The "Algebraic Manipulation of Symbolic Expressions" was basically predecessor to S-exps, but with commas.
Early Lisp used commas as well. The Lisp I Programmer's Manual from 1960 has a note[0] when moving from a theoretical discussion to discussing the actual Lisp system:
"A few discrepancies between the situation as it is and what might be expected from the previous chapter should be noted.
1. The commas in writing S-expressions may be omitted. This is an accident."
By 1962, the Lisp 1.5 Programmer's Manual was saying[1]: "Historically, the separator for elements of lists was the comma (,); however, the blank is now generally used. The two are entirely equivalent in LISP."
To clarify: What bugs me about this isn't really that there are commas. If that makes the parsing simpler, I won't mind having to type them, and having them there doesn't make the code less readable. They might not be needed technically, but I can live with that.
What annoys me is that you can't end a list in a comma:
[ 1, 2 ]
is valid, whereas
[ 1, 2, ]
isn't. This means that if you generate JSON (and if you're using a lower level language you might not want to import a library just for that), you'll have to make a) either the first or the last entry of your sequence a "special case" (omit the comma) or b) backtrack after the string generation and erase the last comma if there are any entries.
On top of that, AFAIK Ecmascript allowed trailing commas since its inception (in array literals, that is), while JSON doesn't.
Yeah, agree with that! Personally, I cannot understand how some people hate significant whitespace in languages. You should be adding whitespace anyway so the braces are redundant and missing out braces is a massive source of super annoying and unhelpful syntax errors where you can be hunting around for ages for the mistake. Incorrect indentation is easy to spot and easy to correct in a few keystrokes in comparison.
People hate significant whitespace because whitespace and indentation are meant for human readability. Introducing the potential for bugs into syntax that a compiler or interpreter shouldn't care about seems unnecessary, or at least not superior to the alternative.
Incorrect bracing and incorrect indentation are equally easy (or difficult) to spot depending on a programmer's familiarity with the language, the features of the editor being used, and the size of the codebase being analyzed, as significant whitespace is just a more complex and brittle form of brackets that uses multiple, visually indistinguishable but incompatible non-printing characters.
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.
FXML is still around, probably best describes as a DSL for Java FX-development. The idea is not to replace HTML, but to replace code with a declarative document, and perhaps to build on the experience developers have today using HTML as a DSL for the browser DOM.
The same is true for Microsoft's XAML, except XAML is a general-purpose configuration language for describing a collection of .NET objects -- in some ways it is comparable to Spring in Java.
Way back in the day, Visual Basic was a system for "writing simple code that creates a collection of objects", most famously for GUIs.
QML is also a general purpose declarative language with data bindings. The UI framework, called Qt Quick, is just one, though most prominent use case. As a non-UI example, there is Qt's own new experimental build system - QBS - http://wiki.qt.io/Qbs_Quick_Reference
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.
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.
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.)
> 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.
It's also interesting to see that they are used for things like coffe machines and the like. This is mostly due to its performance on low-end hardware (you won't want to be using an Atom PC with Windows to control a coffee machine). This in itself is also quite a benefit to Qt - although from a C/C++ developer's point of view it still looks a bit bloated ;-)
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
XAML has a high learning curve and lots of ways to shoot yourself in the foot. But it works well. I shipped an embedded real-time data visualization product that used WPF XAML for the UI and ran perfectly smooth on a second-gen Intel Atom. The latest UWP incarnation of XAML is all native and used heavily in Windows itself.
MVVM is not an anti-pattern, it's just a simple way to communicate changes to a retained-mode UI framework (XAML's rough analog to React's shouldComponentUpdate). Data binding prevents a lot of error-prone glue code.
WPF is very complex. The learning curve is extremely steep. The (early/lack of) evolution of the .NET runtime and the C# language also made WPF more difficult than it would be if it were created today. And, finally, Microsoft never bought into it fully.
That said, it is, by far, the best desktop UI library for Windows-only apps. I wouldn't consider using anything else until/unless the following were equal to WPF. The amount of engineering gone into the framework, the thoughtful design, the critical mass of use.
> 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.
Apart from maybe simple shapes and fills, I think there is little value in adding a complete object-oriented library of scriptable graphics elements into a UI layout / widget language.
For custom drawing needs (charts, data plots, diagrams, etc.), you could use QML Canvas, Context2D and Context3D which offer far greater flexibility with their immediate mode APIs than an object-oriented API could ever provide.
Performance scales with size of canvas. I need an API which scales with the number of objects on the canvas.
> Context2D
Too low level. I don't want to recreate my own subset of SVG-- including handling dirty bboxes and rolling my own viewport.
> Context3D
These are 2d diagrams so a 3D API is definitely overkill.
I'm not making up my functionality needs. My app's frontend is ported from the old Tk canvas interface, and some users end up making diagrams the size of posterboards or billboards. SVG is by no means a sane API but its the only one currently in the entire HTML5 monstrosity that can do everything the old clunky Tk canvas can do.
Not sure where svg vector-effect is (perhaps svg 1.2) but it looks like the value "non-scaling-stroke" is supported everywhere except IE.
Also-- does Qt have an equivalent of devtools can ship with the app so that the state of the view can be queried, mutated, and REPL'd in the user's running instance?
> Also-- does Qt have an equivalent of devtools can ship with the app so that the state of the view can be queried, mutated, and REPL'd in the user's running instance?
However, in my experience on live reloading (with QML, Unity3D and Python), it only works well with environments that don't interface to native code. Else it's way too easy to leave some state hanging in a bad way in a DLL (and then you get undebuggable crashes upon undebuggable crashes).
Likewise, there is no REPL provided (since it's declarative in nature... there are no "instructions" being executed directly, only reactions to actions). But implementing your own takes a few lines. I wonder what its point would be though.
> However, in my experience on live reloading (with QML, Unity3D and Python), it only works well with environments that don't interface to native code. Else it's way too easy to leave some state hanging in a bad way in a DLL (and then you get undebuggable crashes upon undebuggable crashes).
Live introspection/DOM mutation has been a life saver.
For example, there was a strange change to the Gnu/Linux font stack that ended with fonts on Ubuntu 16.04 that measured significantly wider than on Windows, OSX, or even older Gnu/Linux distros.
Seeing the computed value of the font in devtools gave us our first sanity check that indeed we were looking at the same font on all systems.
Measuring the font by injecting a quick script into devtools showed the relevant symptom of the font stack discrepancy that we could then check for and workaround. (It also served as a check that the computed value above was indeed the correct one.)
Interpreted frontend language meant pulling the code change and simply running again from the dev environment. (Admittedly a small benefit over recompiling, but a benefit nonetheless.)
There's actually a decent counterexample of a similar set of problems in a separate branch of the software that uses the old Tk canvas interface. Since it has no (easy) introspection tools to gauge what's going on with the fonts, there was instead a 100+ message thread of people comparing screenshots and staring at zoomed-in pixel differences.
> Likewise, there is no REPL provided (since it's declarative in nature... there are no "instructions" being executed directly, only reactions to actions). But implementing your own takes a few lines. I wonder what its point would be though.
For one thing, it means not having to guess or predict which state might be relevant to a bug report. I can give a user a script to inject and then get back what the result is on their system. I've probably solved a handful of bugs this way, so it's definitely useful.
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"
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.
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.
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.
> 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.
>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.
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.
"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.
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.
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
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?
I think maybe HTML-as-content is declarative, but HTML-as-layout is mostly imperative. I would expect a constraint-solving engine in any declarative layout system. Tables have some minor constraint solving capabilities... So of course we do our best to never use them for layout! Flexbox was definitely a step in the right direction.
I've talked before about an idea to split layout into a new technology, freeing HTML and CSS to only consider content and presentation:
Yes, but the smallest amount of behavior requires the imperative-by-default javascript, and the design is in pratice decided by the results of the interference of two different declarative languages (HTML + CSS).
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.
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.
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)
Accessibility. Simply by using canvas is like throwing away all human-machine interface support stuff which your OS/browser provide and reminds me times of arty Flash pages with awkward navigation.
I mean, back in the 80's we had limited RAM and maximum filename lengths and stuff, so maybe there was a practical benefit.
By "trend", I more mean the trend of continuing to use these sorts of weird numeric contractions of words instead of just saying "localization" or "internationalization" or "accessibility" now that we have computers that can handle big words without breaking a sweat.
There was a much bigger benefit. Try writing those words on a whiteboard, repeatedly, and see what that gets you :)
You can argue till you're blue in the face, it's an established shorthand by now. And shorthand has a point - I don't see you writing "random access memory" instead of RAM either.
Once upon a time, RAM was called "core". We should go back to that. I digress...
I'll concede it's easier to write on a whiteboard, but for other situations, it seems rather silly (and very different from the concept of an acronym or initialism).
I (author) meant that as an example of how you could achieve portability and consistency with HTML5. The canvas approach is NOT what QML does, however.
Not unlike HTML DOM, QML builds a tree of objects from the declarative representation (.qml source code) with discoverable properties. It would be straightforward for accessibility tools to traverse this tree and extract information from it.
As user jcelerier already mentioned, QML has accesssibility features built-in. It provides a tool to annotate any part of the UI with accessibility metadata. HTML has nowhere near such a consistent approach to accessibility.
That's great, but the problem is that the web is and will remain HTML, and as such you kinda have to play ball with exactly what it gives you. Being trivial doesn't stop you from being nonstandard and I really dunno--unless you're going to get every browser under the sun to play with something that isn't any sort of standard, it's spitting into the wind.
Yes, it throws the HTML DOM out of the window. But if it's built as a native standard, nobody will have to reinvent a DOM, because QML has one, and it's better than HTML's one for applications.
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....
It is GPLv3/LGPLv3 licensed. Any company, at any time, could fork all of Qt (and the QML part), do whatever they want, release it however they want (as long as they obey the source availability requirements of the license used, and in the case of the GPL license the final work under the GPL) and Digia could not stop them, because the GPL licenses all include the same patent protection language like how Apache does, and once released under the GPL license a company can't just say "no I take it back you can't use it anymore".
You can restrict future versions, but what exists now is absolutely free to use by anyone. If browsers wanted to adopt QML according to its current API, Digia could never, ever, ever do anything to stop them as long as the products obey the LGPLv3 source version.
You can also create a clean room implementation of QML itself and license it however you want if you never looked at the Qt code. I don't know if QML is patented though.
Betteridge's law of headlines says no, and I really don't see how it would even happen.
QML is a great answer to "a web UI standard" but the web is built on backwards compatibility. Of that restriction were born fantastic technologies and toolkits, such as React, which make the need for an answer kind of moot.
I think this is a case of: "if it were going to happen, it would have happened already". QML has existed for a long time (8 years is like five decades in web years) and it hasn't happened. Same reason I kind of roll my eyes whenever people mention client-side certificates when good CSA solutions are brought up... if it were gonna happen, it would have.
You don't replace HTML, you add a new document type that the browser understands: application/qml, or some such. Just like you didn't replace HTML with JPEG, or JPEG with PNG... In fact, the code is already pretty much written for you by Qt.
Think about the magnitude of what you're saying. Look at how well dart and webp are faring despite a giant behind them...
QML in the browser doesn't fill an actual need, and because it's unknown to most web devs even if perfect support magically appeared in all browsers tomorrow, it would not actually be used right out of the gate.
It was, at one point, but now that all of the browsers autoupdate and mobile device lifespan is about 2 years, it's rare for anyone to test on anything very old. Try submitting a bug to a site that things don't work on IE5 or NN6.
Also wrong, most browsers stopped supporting <blink> and <marquee> years ago (as well as many other outdated features, or plugins such as Java or Flash)
I want to say those are bad examples but nonetheless valid. A better expample would be Javascript's strict-mode situation. In less civilized times, you could do all sorts of terrible shenanigans with javascript, and luckily for developers strict-mode gained support to the point where everyone naturally assumed you were talking about a strict environment. When ES6 came around, those 'sloppy' mode differences made implementing new features tough, so with adopting ES6, 'sloppy mode' was implicitly dropped.
So yes, the web isn't by any means backwards compatible-- but definitely better at it than most ecosystems.
Yes, and the <bgsound> tag as well. What's your point? We're talking about a tiny part of the spec, vs. introducing something like QML to the ecosystem.
[filing under 'things front-end programmers say when they encounter the JavaScript ecosystem']
Yes, QML is nice. Yes, it would be great if everyone used that instead of <your solution here>. But it's not going to happen. What will happen instead is that web-native solutions will outcompete imports again and again, as they have since the dawn of the web, because the shape of the space itself privileges solutions that are able to handle the terrain. Yes, React kind of sucks in places. Yes, its PATENTS file is discomfiting. No, it won't be replaced anytime soon; we literally just got here.
Attempting to replace front-end web dev with markups and paradigms from the desktop is the software equivalent of marching on Moscow. There are better things you could do with your soldier's bodies.
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?