[onsclom]

> 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/

[rubymamis]

> Though slight nitpicks, these breaking changes were probably entirely NextJS changes and not React changes.

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

[onsclom]

> 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.

Gotcha, this makes sense. To be fair, browsers write HTML elements like <input> and <textarea> using C++ too. Though I admit the core Qt Quick components cover more functionality use cases than HTML elements.

> And JS list? There's this[2].

Ooh whoops, good catch on the typed lists. I seen now you can do stuff like `property list<int> intList: [1, 2, 3, 4]`. Looks like I missed this because it was added sometime inbetween 6.2 and 6.4?

Still I'm a bit skeptical, what about lists of lists like `list<list<int>>`? And what about lists of objects? I wish I could quickly test Qt 6.5 myself without setting up the whole dev environment, but qmlonline only supports 5.15.

> JS object (like JSON?)? I'm quite sure QML supports object property.

Whoops, objects are a tricky overloaded word. But yeah, something like a struct in C. For example, TypeScript ensures this code will be totally typesafe at runtime:

  type Person = {
    age: number,
    name: string
  }

  let people: Person[] = []
  people.push({
    age: 24,
    name: "jeff"
  })

In QML it seems you need to go to C++ to define a type like `Person` and expose that to QML?

> Although there is qmllint that warns you of many such things before compilation even[3]. It's great.

Ohh, that would definitely be an improvement. It doesn't look like it does any type checking, but atleast checking for syntax and anti-patterns is something. If Qt gave QML good static typechecking like TypeScript, it would make my QML experience sooo much better. Then the big remaining problem is how unsafe C++ is lol.

> First - using Qt Quick - native performance.

I'm still a bit skeptical about all that QMLScript getting compiled to native code, and it's not like there's zero overhead in Qt's OOP code. It feels like native is a spectrum where C or Rust would be more native, right? If you use native components with C, that should be considered "true" native performance, right? I'm sure Qt/QML is more performant than something like TypeScript with Svelte. But I'm really curious to see by how much.

> 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.

I totally agree property bindings are great. In the same way properties are reactive by default in QML, any variable is reactive in Svelte. Signals and slots are interesting. I always thought its better to avoid them and find a better way to structure things. Signals and slots are component events[3] in Svelte, but people seem to rarely use them. I'm curious to see where you use signals and slots in QML. Maybe I'm missing out here.

Properties, signals, and slots exist in the C++ side too and I have some nightmares about these. The fact that this is all implemented using the Q_OBJECT macro means that when you make any mistakes you get some really gnarly errors. It feels like humans were never meant to see these errors. Maybe I'm just too spoiled by Rust and TypeScript error messages.

Callbacks are really useful in UI programming. They make it possible to do event driven programming. But it feels so rough using callbacks in C++ because functions aren't first class citiziens. In Rust or TypeScript callbacks feel much more sane to use. And when you make inevitably make mistakes, you get much more sane errors.

> They are so simple yet incredibly versatile and powerful. It just makes sense to work with them than any Hooks or whatever in React

I definitely agree that QML bindings are much nicer to work with than React hooks lol.

> Then the Model/View paradigm of Qt fits so well into QML is just awesome.

Ooh interesting. It seems older frameworks were more model/view oriented, but now new frameworks interconnect these more. It's interesting you enjoy this. I find the model and view rarely get changed seperately. New features tend to require changes to both the model and view, so it seems weird to seperate them.

> Well, you can easily grab a binary from our GitHub Actions and try it out[4] or compile it from source

Awesome thanks! I'm looking forward to trying this out and checking out the code. It will be interesting to see if Svelte can compete on any of these things.

> Why is that? Qt is using the underlying 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.

If we call QML/Qt components native-like, then we should also call HTML and CSS native-like. Browsers are built with C++ and render HTML+CSS with accelerated graphics APIs too. There are tons of powerful, interactive HTML elements[1] and when combined with CSS animations you can achieve a lot without ever touching JS.

Browsers just keep getting better. For example, the new View Transitions API[2] means that the browser is exposing hardware accelerated page change animations. Even with current CSS animations, there are lots of GPU accelerated animations that are either 1. not possible with Qt/QML or 2. less performant in Qt/QML.

Maybe you find some built in GPU accelerated feature QML has that browsers do not expose. No big deal, the web has a WebGL API, and the even more powerful WebGPU API is rolling out! We can write our own hardware acceleration using TypeScript!

However, I admit reality is messier than this. With QML its tempting to quickly hack together functionality with QMLScript that should have probably been done through different means. On the web it's the same, but TypeScript seems like a much more sane and safe language than QMLScript.

> 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.

This is so awesome, and I'm excited to see how your journey continues.

I'll definitely stay in touch and let you know how my experiments with Svelte, Tauri, and Rust go.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element

[2] https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

[3] https://svelte.dev/examples/component-events

[rubymamis]

> TypeScript ensures this code will be totally typesafe at runtime:

That's cool. I think QML is going in that direction.

"In addition, Qt 5.14 introduced the possibility to provide type information in function signatures, similar to how it is done in TypeScript:"[1] `function add(a: int, b: int) : int { return a + b }`

> I'm still a bit skeptical about all that QMLScript getting compiled to native code

"Additionally, in Qt 6.3, there will be another compiler: The QML type compiler, or qmltc. With the QML type compiler, you will be able to compile your object structure to C++. Each QML component becomes a C++ class this way. Instantiating those classes from C++ will be much faster than the usual detour through QQmlComponent. qmltc, like qmlsc, is built on the availability of complete type information at compile time. In contrast to qmlsc, though, qmltc has no graceful fallback in case the type information is lacking. In order to use qmltc, you will have to provide all the information it requires. qmltc will be available with all versions of Qt." [1]

I read your entire comment. It takes a lot of effort to respond here. You make some interesting points. I do think each should find the right tool for his job. I found QML very appealing. And I think it keeps improving and I hope they integrate some of the cool security features of typed languages etc. I might not be the best person to respond technically to your arguments, tho. In any case, I'd love to keep in touch. I saw you on Twitter so that's cool. I'm also (more available) on Discord. My username is "rubymamis" so feel free to send a DM (:

[1] https://www.qt.io/blog/the-new-qtquick-compiler-technology