QML Online Now Hosted By The KDE Project For Qt/QML On The Web

[bug77]

brent polarathene My guy has a C/C++, not web background. Probably that makes the difference.

[brent]

brent polarathene My guy has a C/C++, not web background. Probably that makes the difference.

I don't have a web background either (I've been a C and later on C++ developer since ~2008), but that does not mean I'm not aware of current web development. If anything, if you come from a pure C++ background, the embedded JavaScript nature of QML seems to be like a really bad idea. It's probably the most criticized part of QML.

[LubosD]

I've given it a try with a relatively simple QML app and the experience was horrible.

XMLHttpRequest? Broken, status code always 0. WebSockets? Broken.

And after adding workarounds for these bugs, it just crashed switching to the next screen.

[jKicker]

Yes, absolutely. I even started rewriting my code according to best practices cobbled together from other projects.

As far as QML itself is considered, I can't really put my finger on it, it just feels like a badly designed DSL. You have to mix structure and style of your UI (by design!). HTML has a dedicated styling language (CSS), QML doesn't, and it's clearly missing. Your code is going to be much more messy than a modern web application project. And the tooling sucks, even Qt Designer cannot properly handle non-trivial QML code and debugging QML is complicated and limited.

The core of QML is of course layout, and that's pretty messy too. Again, can't put my finger on it, but the tools available are less intuitive and less powerful than what you get in HTML/CSS. There are often different ways to apparently achieve the same thing, but there are differences depending on context. In a complicated nested layout I've seen weird stuff happen that I had to hack around. My fault? Probably. But given how confusing QML's layout system is, this is no surprise.

Then there's components... there are two sets of component libraries (Quick Controls 1 and 2) and they are competing. Quick Controls 2 is the modern and maintained one, but it's not feature complete. Want a tree view? Tough luck, Quick Controls 2 doesn't have one. There's one in Quick Controls 1, but that doesn't help because you can't really embed it sanely in your Quick Controls 2 based app.

However, where it gets really bad is interaction with C++ code. It's an unholy mess. There are a bunch of different methods to interact and it's often not clear which one should be preferred and offers the best trade-off between performance, type safety and easy of use. You generally need to write a lot of code, even for basic data binding. In the best case, this only slows you down, in the worst case, there will be bugs. Lots of them.

Overall, it seems like QML was designed with the idea of writing apps largely in QML and JavaScript with a very slim backend, but the tooling for that simply doesn't exist, so that's a probably a bad idea, too. Tooling support for JavaScript in QML feels like a throwback to 2005 compared to contemporary web development.

I'm sorry, but this comment is very misleading and just shows a lack of understanding and experience. This is coming from a long time QML developer (5+ years) after writing and maintaining multiple cross-platform applications including Android TV, Android mobile and iOS with C++, Java and Objective C integration.

Your issues are regular issues of people expecting HTML behavior which is bad to begin with because HTML was not made for UI app development. You do know that web components exist and what you wrote about separation of styles is completely unwanted in today age and goes against both new approaches in HTML5 and Jetpack Compose for Android and SwiftUI from Apple as few examples. You have a lack of understanding a framework that is completely made for declarative UI development so I can recommend to read more about modern UI development. You can start with Flutter as that is a new hot thing (for a reason).

Due to you mentioning that Layout system in QML is confusing comparing to HTML/CSS then it's again clear lack of understanding and wanting to understand. No, CSS layouting was never called intuitive. You are just used to that pain which is now easier with Flexbox. No new framework is trying to replicate HTML / CSS layouting and styling. For a reason.
On the other hand docs of Qt / QML can explain you all layouting options in a page and why there are more options.

Having and improved version of package is not bad, V2 of that specific package was made for a reason to make it more performant and it's a major version bump. It would be nice to get all improvements with backward compatibility but it's a regular process of improving with major version bump. And Qt does a great job of keeping framework backward compatible given how big it is. Angular 1 vs Angular 2 anyone?
Also your TreeView comment is outdated since TreeView is there and I don't see how not having one premade component makes such a big influence, you get all possible components in all other framework that you ever have to use? I personally never in my life needed a tree view, but I needed a bunch of others that I had to develop as expected.

I do agree that Web has better tooling, just much more people working with it and many companies improving it but comparing tooling for web with QML has no sense. Tooling is s not a framework, and you cannot develop native apps using HTML, there are frameworks trying that but then they have their own tooling with all of the bridge issues ala React Native that you don't have in QML since it's doing native rendering.
I also never seen a good designer tool that people use with modern Web frameworks that you probably think about. Please share me which one there is that supports regular HTML5 or React, Angular, Svelte and that people use it to develop everything in it.

For C++ integration I don't know what to add. If you need to go that route you do need to understand it and read the docs on which methods to use. I don't understand argument of having many methods. Yes. That is what is done. There are methods made for things you need them. If framework supports more things, you get more methods. You should read the docs and understand which one. Really, Qt docs are top notch.

Qt and QML are not perfect, but it's hard to find something that comes close to it for UI development supporting multiple platforms. Flutter is coming close but is quite fresh so has it's own issues due to that. The biggest pain of Qt is their licensee which prevents mass adoption.
I really recommend to people who are coming to modern declarative frameworks to keep an open mind and remember how painful some things are in the framework you are working with. Bashing on something that you don't understand and not wanting to understand will not bring you anywhere.

[Vistaus]

Meanwhile 90% of "modern" web development is with a javascript framework that spits out the html and css on the client except its not in a well designed markup itself, its just javascript functions, arcane overloads, and callback hell.

*cough* Electron *cough*

[mykolak]

Qt and QML are not perfect, but it's hard to find something that comes close to it for UI development supporting multiple platforms.

Very true.

With HTML+CSS I always miss QML features in both layouting and less repeating yourself. HTML has no viable component idea (<template>/<slot> still has far from perfect support). And HTML+CSS has a lot of workarounds. Like base display property is a mix of presentation element itself (block, inline) and its inner layout (flex, grid). It was designed for documents and then application-like behaviour was glued to it.

QML (IMHO) is two heads over HTML+CSS in both performance and usability.