> But in my view, the QML paradigm is extremely consistent, even migrating from Qt5 to Qt6 was quite straightforward. I just updated my website to a new NextJS version and so many things broke in React there were serious paradigm changes if I remember correctly.

Totally fair points here. Though slight nitpicks, these breaking changes were probably entirely NextJS changes and not React changes. NextJS solves a much more complicated problem, full stack web apps. I think it's more fair to compare QML with React as they both focus on simply describing UI.

> I appreciate the native performance I get from compiled C++ code (Most QML code is compiled to C++)[1]

I read the article and I'm skeptical that most QML code is compiled to C++. My understanding from the article is that they are able to compile VERY basic QML code that you manually specify all the types for. The problem still remains that QMLScript is a very dynamic language. 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?

> But I'm not sure how QML is unsafe.

QML is unsafe because it's a dynamically typed langauges. Many errors will not be discovered until runtime! I brought your example over to qmlonline[1] and modified it.

Rectangle {
property int count: 0

Button { onClicked: { count += "1"; } }

Text { text: count.toString(); }
}

This "compiles" fine, runs fine. In fact, it perceives this as fine behavior and continues on without even giving a runtime error when I click the button??

Let's try something even more clearly bad. Let's do `count = "test"`. This "compiles" and starts just fine too?? Finally you get a runtime error when you actually press the button.

I'm really skeptical about how or what C++ this all compiles too, because this is all very much dynamic behavior, and it's not giving us any useful feedback at compile time. These are really simple errors that this "QML compiler" should be catching and presenting to the developer.

These kind of errors are impossible with TypeScript. TypeScript will tell you immediately in your editor when you type this mistake, so you will never get runtime type errors. Going from TypeScript to QMLScript or regular JavaScript is probably the biggest downgrade of all to me. C++ is statically typed thankfully, but what good is having only half of your code statically typed?

> I like React for small projects but as it gets bigger I find it quite cumbersome.

Reading this and "developing in React always felt hacky like using duct tape and glue", I wonder how much of this is actually React and how much is using dynamic JavaScript. If your whole app was dynamic QML code, you'd probably feel like that was hacky too, right? If you have specific examples of things that felt hacky and hard in bigger projects, I'd love to hear that. My hypothesis is that you'd feel like your React projects were much more "solid" and "proper" if you used TypeScript. 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'm curious about what you think QML really excels at. It sounds like it was perfect for quickly making a Kanban prototype? What all did the prototype include? Maybe I should try recreating some portion of it with Svelte. I think it could be interesting to have a direct comparison. If QML has useful tools for building UI that Svelte doesn't, I'd find that really interesting. I'm constantly looking for the best way to build UIs, and right now Svelte seems like the best.

If you remember the specific problem with Tauri, I'd be interested in hearing that. I'm curious about the performance differences between Tauri and Qt apps. There are probably some pros and cons with Tauri's web view approach. I imagine OS native web views might be better at rendering certain UIs than Qt's rendering.

It's cool that you're looking into Rust things too. Rust gives even better compile time feedback than TypeScript which excites me. It's super interesting hearing all your thoughts, and would love to hear more.

[1] https://qmlonline.kde.org/