| HN Mirror

> 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