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?
> 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.
https://github.com/qmlweb/qmlweb/projects/1 shows how much is yet to be done.
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.
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).
Early Lisp used commas as well. The Lisp I Programmer's Manual from 1960 has a note 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: "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...
1: page 4, http://www.softwarepreservation.org/projects/LISP/book/LISP%...
This subject has some coverage in P. Gabriel's and Guy L. Steele's Evolution of Lisp:
Search for "backquote".
What annoys me is that you can't end a list in a comma:
[ 1, 2 ]
[ 1, 2, ]
On top of that, AFAIK Ecmascript allowed trailing commas since its inception (in array literals, that is), while JSON doesn't.
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 don't understand what you're getting at. Qt Creator is FOSS. https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/
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.
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.
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
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.
Of course i would be very happy if I could still do everything done in such way...
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.)
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.
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
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.
To give my reference, I'm getting smooth 1080p 60fps when not too many shaders are involved with Qt on a Raspberry Pi 3.
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.
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:
y: x + 2
onTriggered: x = x+1;
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.
How about patterns and vector effects?
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.
Too low level. I don't want to recreate my own subset of SVG-- including handling dirty bboxes and rolling my own viewport.
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?
Depends. There is Gammaray which can connect to a Qt process (including remotely, quite useful for embedded) & where you can change properties of your objects on the fly : https://www.kdab.com/development-resources/qt-tools/gammaray...
For live reloading, it isn't proposed by default in shipped applications but there are many ways to do it : https://fr.slideshare.net/ICSinc/how-best-to-realize-a-runti.... The IDE nowadays does it for instance : http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat....
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.
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.
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.
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.
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 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.
Single code base to create rich Android, iOS and browser app?
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.
React and Angular and their ilk are too abstracted for my tastes. Too much tooling required.
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.
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.
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.
I've talked before about an idea to split layout into a new technology, freeing HTML and CSS to only consider content and presentation:
It's not the simplest or clearest thing around.
The easiest-to-integrate React/Vuejs components are very close to purely declarative, in my experience.
It behaves like a widget-based programming language toolkit, so you would have global style properties with per-item optional overrides.
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)
Kinda wish we'd stop with this whole "replace the middle of the word with a number" trend, but oh well.
a11y seems to be slightly later. My memory whispers something about mid-90s.
So, maybe not quite as much a "trend" as you assume :)
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?
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.
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).
That strongly suggests that any Qt accessibility stuff will be thrown out the window.
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.
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.
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?
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.
You can browse essentially every single site from 1995 and see exactly what you would have seen at the time.
So yes, the web isn't by any means backwards compatible-- but definitely better at it than most ecosystems.
> if it were going to happen, it would have happened already
Backward compatibility allows another technology to be used side by side with existing one ( WebAssembly ? ).
"How far can you go with MySQL or MariaDB?"
At the very least the "law" needs to be rephrased in a less catchy way, but then no one would reference it.
Seems to me like a clear, coherent and realist answer.
I mean, that's not entirely wrong. You'd go much farther with PostgreSQL. ;)
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.