
Can QML become the next standard for web UI? - jcelerier
https://blog.kutny.net/2017/07/29/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/](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...](http://blog.qt.io/blog/2015/09/25/qt-for-native-
client-and-emscripten/) 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
Just 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-
webass...](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-
webassembly.html)

~~~
martin_ky
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](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.

------
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...](https://www.developereconomics.com/cross-platform-apps-qt-vs-html5)

~~~
virgil_disgr4ce
I expected a lot more. I found this:
[http://doc.qt.io/qt-5/qmlfirststeps.html](http://doc.qt.io/qt-5/qmlfirststeps.html)

~~~
seanwilson
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.

~~~
w4tson
I dislike the way it looks like JSON but isn't.

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.

~~~
seanwilson
> I dislike the way it looks like JSON but isn't.

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.

~~~
btschaegg
> 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

    
    
        SELECT
             Column1
            ,Column2
            ,Column3
            ,[...]
    

Just sayin'.

~~~
kazinator
Dropping the silly commas somehow wasn't obvious right away to McCarthy,
either!

See:
[https://news.ycombinator.com/item?id=14885779](https://news.ycombinator.com/item?id=14885779)

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).

~~~
kbp
> 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."

I wonder when we got unquote.

0: page 24, [http://bitsavers.trailing-
edge.com/pdf/mit/rle_lisp/LISP_I_P...](http://bitsavers.trailing-
edge.com/pdf/mit/rle_lisp/LISP_I_Programmers_Manual_Mar60.pdf)

1: page 4,
[http://www.softwarepreservation.org/projects/LISP/book/LISP%...](http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf)

~~~
kazinator
> _I wonder when we got unquote._

This subject has some coverage in P. Gabriel's and Guy L. Steele's _Evolution
of Lisp_ :

[https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf](https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf)

Search for "backquote".

------
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](https://developer.mozilla.org/en-
US/docs/Mozilla/Tech/XUL)

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

~~~
elygre
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.

~~~
PaulHoule
I have used it. JavaFX is pretty good.

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.

~~~
martin_ky
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](http://wiki.qt.io/Qbs_Quick_Reference)

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

~~~
flavio81
Yes, but "plain HTML with <form> elements and server-side processing" is not
what the users (and thus our customers) expect, for good or bad.

Of course i would be very happy if I could still do everything done in such
way...

------
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](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/](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.)

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

~~~
whowouldathunk
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.

Disclosure: I work at Microsoft.

~~~
jcelerier
> and ran perfectly smooth on a second-gen Intel Atom

To give my reference, I'm getting smooth 1080p 60fps when not too many shaders
are involved with Qt on a Raspberry Pi 3.

~~~
martin_ky
We get interactive framerates ~30fps with Qt Quick on Raspberry Pi B+ with
fullscreen video playback in the background.

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

~~~
recursive
What browser has json rendering?

~~~
zanny
Firefox does. Go open something with content-type json ex:
[https://accounts.google.com/.well-known/openid-
configuration](https://accounts.google.com/.well-known/openid-configuration)
in Firefox and it renders it into a pretty table and even shows you the
headers on the response.

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

~~~
towndrunk
Have a look at the T3 Framework.
[https://github.com/box/t3js](https://github.com/box/t3js) Very simple to use
and overtime you will create a collection of reusable services.

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

~~~
jdmichal
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:

[https://news.ycombinator.com/item?id=13536585](https://news.ycombinator.com/item?id=13536585)

------
ezioamf
Looks very similar to NCL
[https://github.com/PayWithMyBank/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)

~~~
yellowapple
a11y?

~~~
SirensOfTitan
Accessibility

~~~
yellowapple
Got it.

Kinda wish we'd stop with this whole "replace the middle of the word with a
number" trend, but oh well.

~~~
groby_b
I think that ship has sailed long ago. It dates back _at least_ to the late
80s, when IBM(?) or X11(?) manuals referred to l10n and i18n tools.

a11y seems to be slightly later. My memory whispers something about mid-90s.

So, maybe not quite as much a "trend" as you assume :)

~~~
yellowapple
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.

I m2n, w2t is t2s, t1e o3n d2s of t2t m5es?

~~~
groby_b
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.

~~~
yellowapple
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).

------
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....](https://www.kde.org/community/whatiskde/kdefreeqtfoundation.php)

~~~
adrianlmm
It is dual license, and Digia is the only one that release the specifications
(they own them), unleast it liberate its under a commite it is a no go.

~~~
zanny
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.

~~~
FRex
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.

------
clishem
Betteridge's law is strong with this one.

------
mrkrabo
Nobody remembers Wt. :(

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

~~~
bebe3000
It's like native Qt for the web. IMO It is a very good proof of _concept_.

Example:
[https://www.webtoolkit.eu/wt/examples/chat](https://www.webtoolkit.eu/wt/examples/chat)

------
scrollaway
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.

What is this being downvoted for now?

~~~
prewett
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.

~~~
scrollaway
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.

------
BLanen
I hope not... With the stuff around Qt's licensing.

------
undoware
[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.

