6 ms·

Having used both QML and Svelte, I enjoy Svelte a lot more. The reactive APIs are very similar, just declare variables, mutate them, and use them. But Svelte is

Having used both QML and Svelte, I enjoy Svelte a lot more. The reactive APIs are very similar, just declare variables, mutate them, and use them. But Svelte is much nicer for many reasons: 1. It uses modern JavaScript and not some limited custom ES5-like JavaScript 2. Svelte can be used with TypeScript so your UI code can be statically typed 3. The integration with Svelte and VSCode is much better than QML and Qt Creator (the big thing is that IntelliSense is much better at analyzing JavaScript code than whatever Qt Creator uses) 4. Having an actual live reloading dev server is so much nicer than compiling and running for every change 5. Svelte has much better documentation than QML These are just the first things that came to mind, but I could probably keep going for a while. Do you think I'm being unfair to QML? And/or have you used Svelte?

em-bee 3y ago
how would the above QML example be implemented in svelte?
- onsclom 3y ago
  This QML example is implementing the example from the article, and the article already implements this example in Svelte. However, the Svelte implementation becomes even more concise when you inline the functions: <script> let count = 0 </script> <button on:click={()=>count--}>decrement</button> <span>{count}</span> <button on:click={()=>count++}>increment</button> <button on:click={()=>setTimeout(()=>count++, 1000)}> increment later </button> Play with this in the Svelte REPL here: https://svelte.dev/repl/97d42ad98e4b4a929d3c5a3de880e6fc?version=4.1.0 https://svelte.dev/repl/97d42ad98e4b4a929d3c5a3de880e6fc?ver... Doing this, I also realized rubymamis cheated a good bit on their QML version. It's missing the text for the buttons. It's not wrapped in `ApplicationWindow { }`. And there's a bug with their implementation: If you clicked their "increment later" button many times quickly then it would keep resetting the timer and only increment once.
  - rubymamis 3y ago
    Haha I was typing fast just to show the QML syntax. I don't really think good code is about lower amount of lines, but rather more about "making sense". And that's what I tried to show. Regarding the timer, so in your Svelte code a new timer is being created each time? I wonder how to implement the efficiently in QML. I don't think it's as straightforward. EDIT: Probably the best way is to expose QTimer::singleShot (C++) in QML.
    - onsclom 3y ago
      Fair gotcha, yeah honestly I find QML to be super intuitive in the same way Svelte is super intuitive. It feels like two framework authors in very different worlds came to a similar conclusion. > Regarding the timer, so in your Svelte code a new timer is being created each time? `setTimeout`[1] isn't even a Svelte thing, it's a JavaScript API that QML would have access to if it was real JavaScript ;). [1] https://developer.mozilla.org/en-US/docs/Web/API/setTimeout https://developer.mozilla.org/en-US/docs/Web/API/setTimeout
      - rubymamis 3y ago
        I understand, but it's not quite necessary if Qt could add some better functionality exposing C++ code in QML. Luckily, someone created a cool library that allows you to create singleShot timer in QML as follows:[1] `lqtUtils.singleShot(5000, () => console.log("Hello!"))` [1] https://stackoverflow.com/a/75288105/5865379 https://stackoverflow.com/a/75288105/5865379 I also used his library to share ENUMs between QWidgets (C++) and QML.
rubymamis 3y ago
1. Yes, but I never found it limiting. If I need to write some complex logic I mostly do it on the C++ side (that's should probably be the best way anyway). 2. True. 3. Yes, Qt Creator is very lacking in that department. There are many instances where it doesn't recognize certain commands and you need to guess if you're writing correctly or not. 4. Live reloading is possible in QML. See[1] (But this should definitely be the default in Qt Creator). 5. I agree that QML documentation is lacking. That's probably my biggest pain point. Some of the examples also use deprecated/bad-practice code which is annoying (eg, using that magic `index` property rather than defining it as a required property. I think you have fair points. I actually have a doc with similar things that QML needs to improve in. I never tried Svelte but I'm familiar with React, and I must say that Qt/QML is a breath of fresh air after using React. Developing in React always felt hacky like using duct tape and glue compared to building something properly which QML/QT feels like. Apart from the points above, I still think QML has been great for my productivity and I'm impressed how easy it is to develop with it complex UIs easily. I've been developing a feature in my Qt C++ app in QML that turns Markdown tasks into Kanban[2]. It worked out perfectly. The tasks processing is done in C++ which sends the data to QML. [1] https://github.com/patrickelectric/qhot#integrate-in-qtcreator https://github.com/patrickelectric/qhot#integrate-in-qtcreat... [2] https://i.imgur.com/C1O4Nbu.gif https://i.imgur.com/C1O4Nbu.gif
- onsclom 3y ago
  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.

em-bee 3y ago

how would the above QML example be implemented in svelte?

onsclom 3y ago
This QML example is implementing the example from the article, and the article already implements this example in Svelte. However, the Svelte implementation becomes even more concise when you inline the functions: <script> let count = 0 </script> <button on:click={()=>count--}>decrement</button> <span>{count}</span> <button on:click={()=>count++}>increment</button> <button on:click={()=>setTimeout(()=>count++, 1000)}> increment later </button> Play with this in the Svelte REPL here: https://svelte.dev/repl/97d42ad98e4b4a929d3c5a3de880e6fc?version=4.1.0 https://svelte.dev/repl/97d42ad98e4b4a929d3c5a3de880e6fc?ver... Doing this, I also realized rubymamis cheated a good bit on their QML version. It's missing the text for the buttons. It's not wrapped in `ApplicationWindow { }`. And there's a bug with their implementation: If you clicked their "increment later" button many times quickly then it would keep resetting the timer and only increment once.
- rubymamis 3y ago
  Haha I was typing fast just to show the QML syntax. I don't really think good code is about lower amount of lines, but rather more about "making sense". And that's what I tried to show. Regarding the timer, so in your Svelte code a new timer is being created each time? I wonder how to implement the efficiently in QML. I don't think it's as straightforward. EDIT: Probably the best way is to expose QTimer::singleShot (C++) in QML.
  - onsclom 3y ago
    Fair gotcha, yeah honestly I find QML to be super intuitive in the same way Svelte is super intuitive. It feels like two framework authors in very different worlds came to a similar conclusion. > Regarding the timer, so in your Svelte code a new timer is being created each time? `setTimeout`[1] isn't even a Svelte thing, it's a JavaScript API that QML would have access to if it was real JavaScript ;). [1] https://developer.mozilla.org/en-US/docs/Web/API/setTimeout https://developer.mozilla.org/en-US/docs/Web/API/setTimeout
    - rubymamis 3y ago
      I understand, but it's not quite necessary if Qt could add some better functionality exposing C++ code in QML. Luckily, someone created a cool library that allows you to create singleShot timer in QML as follows:[1] `lqtUtils.singleShot(5000, () => console.log("Hello!"))` [1] https://stackoverflow.com/a/75288105/5865379 https://stackoverflow.com/a/75288105/5865379 I also used his library to share ENUMs between QWidgets (C++) and QML.

rubymamis 3y ago

1. Yes, but I never found it limiting. If I need to write some complex logic I mostly do it on the C++ side (that's should probably be the best way anyway). 2. True. 3. Yes, Qt Creator is very lacking in that department. There are many instances where it doesn't recognize certain commands and you need to guess if you're writing correctly or not. 4. Live reloading is possible in QML. See[1] (But this should definitely be the default in Qt Creator). 5. I agree that QML documentation is lacking. That's probably my biggest pain point. Some of the examples also use deprecated/bad-practice code which is annoying (eg, using that magic `index` property rather than defining it as a required property. I think you have fair points. I actually have a doc with similar things that QML needs to improve in. I never tried Svelte but I'm familiar with React, and I must say that Qt/QML is a breath of fresh air after using React. Developing in React always felt hacky like using duct tape and glue compared to building something properly which QML/QT feels like. Apart from the points above, I still think QML has been great for my productivity and I'm impressed how easy it is to develop with it complex UIs easily. I've been developing a feature in my Qt C++ app in QML that turns Markdown tasks into Kanban[2]. It worked out perfectly. The tasks processing is done in C++ which sends the data to QML. [1] https://github.com/patrickelectric/qhot#integrate-in-qtcreator https://github.com/patrickelectric/qhot#integrate-in-qtcreat... [2] https://i.imgur.com/C1O4Nbu.gif https://i.imgur.com/C1O4Nbu.gif

onsclom 3y ago
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.