[pcwalton]

And instead of JS, we'd be stuck with C++. Not an improvement.

At least the frontend stack with the largest deployment—HTML, CSS, and JS—has a garbage collector and is memory safe. With C#/VB.NET on Windows, Swift on Mac/iOS, and Java on Android ascendant, this is now obviously the way to go. Imagine if we had permanently made the mistake of saddling the Web with manual, error-prone memory management.

[makmanalp]

Not true at all! Have you tried PyQT? It was in my experience an absolute pleasure to use, and I think satisfies your main criteria. No reason why there couldn't be similar bindings for any given language you prefer, though I understand the merits of standardizing on one.

But also the point is that the Qt runtime would be part of the browser, which is usually all C++ or Rust or whatever anyway - not the web programmer's responsibility.

What makes me sad is that Qt for a very long time has had a very well thought out ways of handling the complexities of UIs, including separating view from layout from business logic, doing layouts properly, they even have a pretty and lightweight DSL for defining UIs, which you can then style with a CSS-ish language. And a non-terrible UI builder on top of that. It even does responsive UIs these days! Granted, how well this would handle something as complex as current webapps is an interesting question, but they've always kept up with the changes, no problem.

Also they did proper threads and event loops, data storage and query APIs, serialization, networking and sockets, highly performant 2D and 3D graphics (GPU-accelerated stuff!), an embedded browser, and all this was (and is) all cross-platform! It really was miraculous magic that we had this circa 2005-2007, and it's frustrating to see bits and pieces of this just recently getting web standards. If in this day and age I see one more proposal for how to do javascript promises or Commonjs / AMD / ES6 modules or something I'm going to die of frustration and exhaustion. :-(

[sevensor]

I'm paid (in part) to develop a GUI application with PyQt. It's excellent. Riverbank Computing deserves every penny. And QOpenGLWidget + PyQt is far and away the easiest way to get off the ground with modern OpenGL.

[Matthias247]

Theres some truth around it. While QML may be nice I found the total experience of the QT stack lacking. It's still required to do large parts of the application in C++, since QML is mainly the View part. The impedance mismatch between the c++ and QML parts is huge compared to an environment that only uses a single language. I was part of some embedded system projects that used Actionscript (Adobe AIR) for some former projects and moved to QT in newer ones. For me personally it felt like a step backwards, from being able to implement the whole application in a single language with reasonable properties into a split world where I still need to use native code with all it's downsides. I don't want to say Actionscript is great here (it's for me somewhere between plain ES5 JS and Typescript) - I would also prefer a uniform Java or C# experience (as available on Android or Windows platforms) compared to a mixed C++/QML setup.

I see the main proposition of QT/QML in providing a framework that is not tied to a particular platform. The main thing that comes close are browser engines, but many people will find their huge footprints too large for using them for embedded applications (or partly even standalone desktop apps).

[shmerl]

> it felt like a step backwards, from being able to implement the whole application in a single language with reasonable properties into a split world where I still need to use native code with all it's downsides.

I see a clear benefit in separating the language for the UI from the application logic language. Having choice of the second is good. Otherwise you are limited a monolithic structure, and need to reinvent the way to define UI in each language.

[beders]

Using a document description language for general application development is and remains INSANE.

The browser is an atrocious, non-sensical platform that was invented to display Hypertext, not to run apps. Now look what we got? 5 new JS frameworks per month, because of some minuscule, often fabricated productivity gain. Various competing improvements to make CSS somehow manageable and an untyped, arcane and hard to optimize language on top of it. And we still struggle to make decent looking and performing apps. It's stupid.

[kmicklas]

> Imagine if we had permanently made the mistake of saddling the Web with manual, error-prone memory management.

Sounds like WebAssembly :)

[pcwalton]

Which is why I'm glad that Web Assembly is offered in addition to a language with a garbage collector and a low learning curve.

(Note that, of course, I'm not opposed to wasm's existence: it's important for many use cases.)