5 ms·

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 en

• rubymamis 3y ago
  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 https://www.qt.io/blog/the-new-qtquick-compiler-technology [2] https://www.youtube.com/watch?v=0HEJFYSxbB8 https://www.youtube.com/watch?v=0HEJFYSxbB8 [3] https://www.rubymamistvalove.com https://www.rubymamistvalove.com
  • ogoffart 3y ago
    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 https://slint.rs
    • rubymamis 3y ago
      > 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 3y ago
    > 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/ https://qmlonline.kde.org/
• JanisErdmanis 3y ago
  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 3y ago
    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_layout/Flexbox https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
    • JanisErdmanis 3y ago
      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.