What dif­fer­enti­ates front-end frame­works

For simple use cases templating is much better as well. It's only in complex state management that I find MVU is worth it.

Yes, you're right that's probably the case.

> I read the article and I'm skeptical that most QML code is compiled to C++.

Well, all the core Qt Quick components are written in C++[1]. Other components either reuses them in C++ or QML. So they're mostly C++ underneath.

> QML doesn't even allow you to type your list or object properties! How much of your QML code doesn't touch lists or objects?

What do you mean? JS object (like JSON?)? I'm quite sure QML supports object property. And JS list? There's this[2].

> QML is unsafe because it's a dynamically typed languages.

I get your point. Although there is qmllint that warns you of many such things before compilation even[3]. It's great. It's a shame they don't easily integrate it into Qt Creator by default. It saved me many errors. In your first example, I wonder why it does its behavior where it concatenates an int like a string. That's weird.

> The facts are that your users would run into much less runtime errors with TypeScript code than C++/QMLScript code. Also, TypeScript provides much more immediate feedback while developing.

I think that's a good take. And maybe something Qt should consider adding on top of QML.

> wonder how much of this is actually React and how much is using dynamic JavaScript.

I just remember handling state changes wasn't that natural to me (maybe it's the use of Hooks?). TypeScript does sound interesting, but I'm a QML convert for now.

> I'm curious about what you think QML really excels at

First - using Qt Quick - native performance. But talking about the language itself - I can't get over how amazing property bindings and signal and slots are for state changes. Just these alone would make me quit any web framework. They are so simple yet incredibly versatile and powerful. It just makes sense to work with them than any Hooks or whatever in React. Then the Model/View paradigm of Qt fits so well into QML is just awesome.

> What all did the prototype include?

Well, you can easily grab a binary from our GitHub Actions and try it out[4] or compile it from source. The basics for the Kanban were to 1. Process the markdown tasks in TextEdit 2. Beautiful interface 3. Beautiful drag and drop like `react-beautiful-dnd` 4. Markdown inside of tasks. 5. Rendering fast with even thousands of tasks.

> I'm constantly looking for the best way to build UIs, and right now Svelte seems like the best.

Me too. But I'm reluctant to non-native performance anymore. I had enough of Electron apps. That's why I was trying React Native (I had a good experience with it but I still prefer QML) and Tauri. I really can't remember why I disliked tauri (maybe i tried to create a custom window decoration but couldn't?). If you ever give it a shot let me know what you think about it. But then again, I'm sold on the flexibility of Qt C++ together with QML.

> I imagine OS native web views might be better at rendering certain UIs than Qt's rendering.

Why is that? Qt is using the underline accelerated graphics APIs to render its content[5]. Even if a component isn't native we say it's native-like because it still uses the native graphic API just not the native component.

> It's super interesting hearing all your thoughts, and would love to hear more.

Thanks! I learned a lot from what you're saying. I have plans to create an ecosystem of open-source cross-platform apps, so I've been deliberating for the longest time on which framework to choose. For now, I've settled on Qt/QML. It has its cons. But that's why I like talking about it with other people so I can document these, file the right reports and maybe improve it as time goes by. After releasing the next version of my note-taking app I plan to migrate the UI completely to QML and create an adaptable/responsive app that will share the same source for desktop and mobile, taking inspiration from MAUI apps[6] that our based on MAUIKit[7].

[1]https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/...

[2] https://doc.qt.io/qt-6/qml-list.html

[3] https://doc.qt.io/qt-6/qtquick-tool-qmllint.html

[4]https://github.com/nuttyartist/notes/actions/runs/5565887776

[5] https://doc.qt.io/qt-6/topics-graphics.html

[6] https://mauikit.org/apps/

[7] https://mauikit.org

I think your example on the flexbox use for two pane view illustrates that well. Although I have no experience of using it I get that the gist of it is the same of a RowLayout. It’s a good abstraction for listing many items of the same kind which need to respond dynamically with the change of window dimensions. But when I really need to place two panes 10px appart or put elements on top of it in the bottome left corner, bottom right corner and align margins of the content within the pane anchoring elements manually is so much easier. I remember when I started to learn QML my first instinct was to find where can I make a table and align elements within it where instead I just needed to use anchors.

The beauty of QML is that I can treat RowLayout and Row as elements written in QML itself. If I recall accurately it is possible to loop through child elements and assign properties to them such as anchors with respect to sibiling elements. The abstraction thus is more fundamental.

> Svelte and other modern UI frameworks prefer composition over inheritance

Inheritance is the right abstraction for the UI elements. For instance I don’t need to predict all properties in advance for my custom bottom implemntion when used in the code. Assuming that all of them are available is quite powerful and allows to experiment in place. This work exceptionally well in QML but not in OOP languages in general. Nevertheless, can you come up with `footguns of inheritance` to which QML is susceptible to?

> Svelte uses file based components as well. Each file is its own module in TypeScript/JavaScript.

This sounds interesting. I will give it a try on someday when I will need to make an UI in HTML.

If you start with such a statement, it would be best to follow up with proof instead of something unrelated.