[onsclom]

Thanks for the thoughtful response. It's interesting hearing from someone who actually likes Qt. I use both React and Qt/QML for work, and I have a hard time enjoying the Qt/QML work. Maybe I'm missing something or doing things wrong?

That reloading tool is cool, though its not quite as useful as modern dev servers. It seems like this simply restarts the app on every change, but modern dev servers remember your state too.

I'm curious to hear more about your React experiences. I don't love React, but I still prefer React+TypeScript over Qt+QML. With TypeScript on the strictest setting, programs are much safer than with QML or Qt. We both know QML is very unsafe. And after using TypeScript and Rust, I'm realizing C++ is a very unsafe language too. It has unexpected nulls, memory leaks, seg faults, etc. I find C++ such a rough language to use, and that could be it's own mega rant. Qt's crazy macro system makes things even worse and generates some crazy errors.

There are so many options for building great cross platform UIs now. Tauri, Flutter, React Native, etc. Those all seem to have a better dev experience than Qt/QML. If performance and safety are really important, then you can use Tauri and write your critical code in Rust. There are also UI frameworks for Rust popping up like Dioxus so you can write everything in Rust.

Your "Better Notes" app is amazing and that Kanban is looking amazing. Though, I feel like you're a great dev making great stuff albeit Qt/QML, not because of Qt/QML.

[JanisErdmanis]

Perhaps your experience with QML would be more pleasant if you would write backend in Rust or Julia (my current choice). In Julia I find that it is particularly easy to iterate as it avoids any compilation step although that is not as smooth as using VS Code with hot reload on the side. There is also Felgo for reloading which I guess also preserves the state, but I have not tried it yet.

One quite an advantage for QML is how easy it is to align elements to get started. Personally, I find it quite frustrating to get HTML to do what I want whereas in QML having only used for two months I already see how to model `Kanban` UI with QML.

[onsclom]

I still don't get what advantage QML has over something like Svelte. Writing the QML backend with Rust would be nicer, but why wouldn't I just write my front end using Svelte/TypeScript with something like Tauri at that point? With statically typed languages you get autocomplete, more instant feedback, more editor integration for things like renaming functions variables, and the end result won't have type errors at runtime.

Felgo is what I was hoping for, good find! That covers one pain point, but there's still many, many more. QML does have a simple and great list of components to get started with, where as HTML and CSS have accumulated many years of cruft. But, that being said, aligning elements into rows and columns is easy using CSS flexbox[1]. Flexbox has the benefit of being much more versatile than QMLs layout tools as well. I imagine using flexbox you could make the Kanban UI just as easily, and you'll probably run into less limitations.

[1] https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...

[JanisErdmanis]

The flexbox does not seem to match the power of QML. For instance, I can have a two-pane view as simple as:

Text {

    anchors.top : parent.top

    anchors.bottom : parent.bottom

    anchors.left : parent.horizontalCenter

    anchors.right : parent.right

    anchors.topMargin : 10

    text : "Hello World"

}

which does not reference any dimensions of the objects. It is easy to reference an anchor of a sibling and other parent elements when needed.

Also, making new components is easy; I can inherit properties of a parent element, add my properties and put them in a file for later reuse is something I use extensively. Building each component carelessly using whatever mockery to get the look I need and then isolating it with its own namespace is relieving.

[onsclom]

Thanks for the nice response!

> The flexbox does not seem to match the power of QML. For instance, I can have a two-pane view as simple as:

I'm a bit confused by this example. When you make the other pane wouldn't you need to define all of its anchors too? It seems like the more standard QML approach to a two-pane is using RowLayout[1].

  RowLayout {
      anchors.fill: parent
      Rectangle {
          Layout.fillWidth: true
          Text {
            text: "pane 1"
          }
      }
      Rectangle {
          Layout.fillWidth: true
          Text {
              text: "pane 2"
          }
      }
  }

I agree this is pretty nice and intuitive, but flexbox makes this problem easy too.

  <div style="
    width: 100%; 
    height: 100%; 
    display: flex;
  ">
    <p style="flex: 1">pane 1</p>
    <p style="flex: 1">pane 2</p>
  </div>

Yes inline css has problems, but I didn't want to scare you away with Tailwind[2] and I think inlined CSS makes this example clearer.

> It is easy to reference an anchor of a sibling and other parent elements when needed.

It seems like by composing layouts in QML you can avoid a lot of manual anchor setting. Though layouts do have their limits. Is that why you resort to setting anchors manually? Flexbox is much less limited and flexbox layouts compose really well.

Do you have examples of UI layouts you feel QML solves intuitively that flexbox can't solve intuitively?

> Also, making new components is easy; I can inherit properties of a parent element, add my properties and put them in a file for later reuse is something I use extensively

Svelte works the same exact way. Well, except for the part that new components do not inherit from existing components. Svelte and other modern UI frameworks prefer composition over inheritance[3]. Composition allows you to be just as expressive, but without the footguns of inheritance. If you have a specific UI problem you think inheritance solves well, I'd be happy to try and create a matching composition based solution.

> Building each component carelessly using whatever mockery to get the look I need and then isolating it with its own namespace is relieving.

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

If you have rebuttals or other additional things to add I'd love to hear it!

[1] https://doc.qt.io/qt-6/qml-qtquick-layouts-rowlayout.html

[2] https://tailwindcss.com/

[3] https://en.wikipedia.org/wiki/Composition_over_inheritance

[JanisErdmanis]

> Do you have examples of UI layouts you feel QML solves intuitively that flexbox can't solve intuitively?

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.

[onsclom]

> two panes 10px apart

`gap: 10px`

> put elements on top of it in the bottom left corner, bottom right corner and align margins of the content within the pane anchoring elements manually is so much easier

These instructions seem a bit more vague. If you make this visually or with QML I'm sure I can replicate it in an intuitive way with flexbox.

Flexbox has `align-items`, `justify-content`, `align-content` which covers all the needs of aligning to centers or corners. `padding` and `margin` work exactly like you'd expect. Unlike QML's layouts, you can also enable `flex-wrap` so content automatically wraps when it overflows the allocated space.

Maybe you're also wondering, how do I memorize all these flexbox properties? I don't! Chrome dev tools give you a GUI for editing a flexbox[1], isn't that really nice?

With all these tools, hopefully it becomes clear that you never need to manually define anchors. You can compose these layouts to build whatever complex layouts your heart desires. But, if you are still really attached to the anchor workflow, you can do that with CSS as well. For example, `position: absolute; bottom: 100%; right: 100%` would anchor a child element to the bottom right of its parent.

> The beauty of QML is that I can treat RowLayout and Row as elements written in QML itself.

I totally agree here. My Svelte example from above would become:

  <RowLayout>
    <p>pane 1</p>
    <p>pane 2</p>
  </RowLayout>

What if I told you it's totally trivial to make this RowLayout component yourself in Svelte? This could totally be valid Svelte code! If this sounds interesting, this example[2] is a great starting point. And it would be even more trivial to pull in a great component library like Skeleton UI[3] which does stuff like this for you.

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

Hopefully this RowLayout example makes it clear that Svelte can also loop through child elements and assign properties.

> Inheritance is the right abstraction for the UI elements

How are you so sure about this? React is one of the most popular and successful tools for building UI elements, and it avoids inheritance entirely. Do you think React's approach is totally offbase? Similarly, Rust and Go do not have inheritance at all. Do you disagree with their design?

> For instance I don’t need to predict all properties in advance for my custom bottom implemention when used in the code. Assuming that all of them are available is quite powerful and allows to experiment in place.

You can expose properties with composition based elements too! You don't need inheritance to support this workflow.

> Nevertheless, can you come up with `footguns of inheritance` to which QML is susceptible to?

I think the composition over inheritance wiki page[4] explains things much more elegantly than I ever could. Though I do think I made a mistake. Does inheritance actually exists in QML land? I don't think so.

It feels like you compose things very similarly to Svelte or React. Maybe it's a just a semantics thing, but imagine HelloText.qml:

  Text {
    text: "hello world!"
  }

Does HelloText inherit from from "Text"? I'd say no. HelloText simply instantiates Text and sets its' text property to "hello world". Though I imagine you would say HelloText inherits from Text and overrides the text property?

Compare this to the Qt Widget world where the difference between inheritance and composition are much more clear. Sometimes a Qt Widget doesn't expose the properties or functionality you want. The best scenario is when Qt Widgets do expose the properties you need. Then you can instantiate them and change those properties. Notice that even Qt Widgets sometimes expose properties without inheritance! When defining bigger fancier widgets, why require inheritance? Break them into smaller parts and expose useful properties. Then you and other programmers can compose custom behavior without going through the sludge of inheriting and overriding!

Perhaps we already agree on that part and it was just a semantics issue about whether QML is actually using composition or inheritance?

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

Yay, I'm interested to hear what you think!

[1] https://developer.chrome.com/docs/devtools/css/flexbox/

[2] https://svelte.dev/examples/slots

[3] https://www.skeleton.dev/

[4] https://en.wikipedia.org/wiki/Composition_over_inheritance

[rubymamis]

Thanks for the kind words!

> Maybe I'm missing something or doing things wrong?

To be fair, I have many annoyances with Qt Quick. I think many of the components don't look and work native out of the box, requiring significant customization that is time-consuming compared to what you get out of the box by using many libraries alongside React. And there are these other annoyances that we already talked about. 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. I also enjoy working with Qt's Model/View, I appreciate the native performance I get from compiled C++ code (Most QML code is compiled to C++)[1], the community is very helpful, etc.

> I'm realizing C++ is a very unsafe language too.

Yes, and I think programming languages like Rust are very cool. I know there are Qt bindings for Rust. But I'm not sure how QML is unsafe. Probably because it compiles to C++? Converting Qt Core itself to Rust is quite an initiative that I'm not sure is necessary. But what is cool is that you can write your UI in QML (compiled to C++ somewhat safely if you trust Qt) and write your app logic in Rust[2]. I hope to see more things like that.

Regarding my React experience, I developed a fully working online marketplace in React + NextJS (but discarded the idea), a React Native app that finds rhymes for words (but didn't publish because chatGPT does it better in a way), and my personal website[3] is in React + NextJS - I love this combo for developing websites, I find it so easy and the integration with Vercel is amazing.

I like React for small projects but as it gets bigger I find it quite cumbersome. Though if we're talking about websites I guess it's one of the best approaches (although Svelte looks good but I never tried it).

React Native is so good because they cracked it with components behaving and looking like native components (well, they are the native components I guess). But I prefer to work with Qt/QML. I thought it would take me a long time to learn it but I bought a good online course from Udemy and in a day I knew all the basics, the next day I had a working prototype for my Kanban.

I tried Tauri as well, it sounds good on paper but when I tried it I didn't really like it. I don't remember why but I remember wrestling too much with things not related to actually writing code.

I keep an eye on Rust GUI frameworks but haven't seen something promising yet. I never heard of Dioxus before so I'll check it out, thanks!

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

[2] https://www.youtube.com/watch?v=0HEJFYSxbB8

[3] https://www.rubymamistvalove.com

[ogoffart]

I'm the author of rust binding for QML (the qmetaobject crate). The idea is that this is "safe" because your Rust code is safe, and QML is also supposedly safe. The implementation of QtCore/QtQuick is not your code to maintain. So hope that other people made it safe. See it as an abstraction is just like the Rust standard library that uses lots of unsafe.

But anyway, I'm also making Slint [0], a toolkit developed in Rust, inspired from QML. So that even the implementation of the toolkit is safer.

[0] https://slint.rs

[rubymamis]

> is not your code to maintain

Exactly, that's what I meant, if I trust QtCore/QtQuick, writing the UI QML and logic in Rust is a pretty good idea. Although I must say that the latest Qt versions Qt 6.5.0-6.5.1 came with two serious bugs for me causing me to revert to Qt 6.4.3. So even that comes with a grain of salt.

I have been keeping my eye on Slint! I must admit, the use cases shown on your website don't look attractive. First, the apps don't seem useful (some random analytic panel, printer demo, and widget gallery) and they don't look good. If I may suggest, put there a simple TODO app that everyone is been taguht these day how to develop one in all the new frameworks. Maybe another app similar to that. It's going to be much more practical and people can have a sense of what is possible to do in Slint. In any case, I have been coming to check Slint every few weeks to check the progress so it's very cool to speak with the author. I wish you the best with it! If you need more feedback on the website's UX or anything don't hestiate to reach out: ruby . mamistvalove at gmail . com

[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