4 ms·

On the contrary, it's time to move to JS for the UI of desktop applications as well. We've seen this approach become more and more popular with Electron over th

On the contrary, it's time to move to JS for the UI of desktop applications as well. We've seen this approach become more and more popular with Electron over the last 10 years.

pdimitar 2y ago
If you say so. Take a look at Slack and Teams and tell me that's what a performant and lagless UI feels like. ...Oh? What's that? I am hearing something faint in the distance, like... "their devs are not using JS well", maybe? Tell you what. If a technology can be held wrong, then it's a bad technology. Which, yes, encompasses most technology nowadays. You heard me.
- foldr 2y ago
  But can you point to an app that has the same UX functionality as Slack that's been successfully implemented using Qt or another native toolkit?
  - pdimitar 2y ago
    Wish I could but many people gave up and started using Electron due to employability. And we're stuck with crappy laggy UIs. I remember the MirandaIM multi-messenger from 20+ years ago very fondly... 50MB RAM usage and I was signed to 4 services, on a computer that my smartphone today can emulate 16 of, simultaneously, and it was still running faster than you can blink. Ehhhh, good times. Electron/JS is a herd just running in one direction, personified. The fact that something is popular does not imply quality, not at all. Most of the time it implies that everybody settled on it and does not want to hear otherwise for various reasons (in this case: money, as employers are never going to give you the requisite time to build stuff with Qt or others).
    - foldr 2y ago
      It could be that Qt would work better and no-one is using it for the sorts of reasons that you mention. But I think the more plausible explanation is that no UI library can compete with what the browser offers anymore. This would hardly be surprising. The person hours invested in HTML+CSS rendering vastly exceed those invested in Qt or any other UI lib. The kind of argument you're making would be much more convincing if there were relevant examples of Qt-based apps that provided a superior user experience to the Electron apps you're criticising. I don't personally find Electron apps laggy in general. VSCode is very responsive, for example.
      - pdimitar 2y ago
        Yeah VSCode is fine, I agree. But as mentioned above, if one can screw up their Electron app to be as laggy as Slack then the tech is not good. I stand by that statement. > The kind of argument you're making would be much more convincing if there were relevant examples of Qt-based apps that provided a superior user experience to the Electron apps you're criticising. That's arguing in circles and it's the chicken-and-egg problem. Toolkits like Qt get less and less mindshare because Electron is desired and is encouraged by employers. I can't speak for Qt in particular btw, just using it as an example here, but my point is that it could be the best UI toolkit ever but since it takes a little more time to spin up an app with it then the business will want you to not use it. Hence, I can't show you those Qt apps. I feel that in these discussions people just blindly trust popularity to be an indicator of quality. I have a huge problem with that mindset and my career has seen the exact opposite, many times. Hence my comments. And if you want to take away just one thing from our discussion, it's this: please don't mistake Electron's popularity with the idea that Electron is the best UI toolkit.
        rubymamis 2y ago
        One obvious reason why Qt is less popular is the ability for companies to deploy web apps (non Electron, but in the browser). Many end users expect a desktop/mobile app to also be accessible using the browser. I'd argue that QML is an order of magnitude easier to develop than any other web frameworks (yes, you do have to get familiar with it, and if you made some apps before you could re-use some essential, battle-tested components). I hope to maybe share/sell some of mine some day. I'm not sure what to answer regarding the browser experience. WASM isn't really there, isn't it? I haven't had a chance to test it on my own apps yet tho. I recently had a thought that maybe that Qt Company should also target HTML/CSS/JS generation of a QML file. Another, more interesting thought would be for browsers to be able to process and render QML files natively (but that won't happen without substential market share).
  - rubymamis 2y ago
    I'm building a chat app - well, a client for LLMs using Qt (QML + C++). It's highly performant with beautiful animations: https://rubymamistvalove.com/client.mp4 https://rubymamistvalove.com/client.mp4 I also created a native block editor (like Notion's) in QML and C++: https://get-notes.com https://get-notes.com I really hope that I can show that Qt with QML is a viable alternative to the inefficient resource hogs that are Electron/web apps.
- DecoySalamander 2y ago
  I use Discord daily and can't really call it slow and laggy, it feels adequate if anything. Can't really comment on Slack and Teams - I've obviously used both, but haven't been a heavy user of Teams and never was in a large "corporation-wide" Slack instance. I have, however, been a heavy user and developer of a Slack competitor. Not surprisingly, it had a lot of problems, but most of them stemmed from a) clumsy handling of megabytes of chat logs, b) a codebase that grew organically out of a startup project and needed a major rewrite, c) misallocation of resources (for the longest time, everything Electron-related was handled by a single developer in a satellite office). In my opinion, we would have had the same performance issues and bugs if it had been developed in any other language. We actually had some Qt apps that we deprecated and rewrote in JS as part of the main client - there was no user-noticeable performance drop, but significantly fewer crashes.
  - pdimitar 2y ago
    ...OK? It was already mentioned that people can do better apps with Electron than others. Not surprising. My objection is that the possibility to make laggy and bad apps exists. It should not exist. As for what problems a Slack competitor faces, well, I am not interested. That's the dev team's problem and not mine. I want a lagless Slack.
    - DecoySalamander 2y ago
      > the possibility to make laggy and bad apps exists. It should not exist I see. Then the only way forward is to stop all software development altogether and enjoy memories of apps that we used 20 years ago when we were much younger, and fantasies of apps that we could build with newly acquired wisdom, but will not.
      - pdimitar 2y ago
        Funny, still not what I said. Progress is way too slow and blindly follows local maximii. That's not OK. That's the part I am expressing displeasure with.
ogoffart 2y ago
It's also possible to use JS (or TypeScript) on the desktop, without having the need for a browser or a webview. That's for example what we're trying to do with Slint https://slint.dev https://slint.dev Then you get the good part of javacript for your application logic, without the bloat and attack surface of a browser.

On the contrary, it's time to move to JS for the UI of desktop applications as well. We've seen this approach become more and more popular with Electron over the last 10 years.

pdimitar 2y ago

If you say so. Take a look at Slack and Teams and tell me that's what a performant and lagless UI feels like. ...Oh? What's that? I am hearing something faint in the distance, like... "their devs are not using JS well", maybe? Tell you what. If a technology can be held wrong, then it's a bad technology. Which, yes, encompasses most technology nowadays. You heard me.

foldr 2y ago
But can you point to an app that has the same UX functionality as Slack that's been successfully implemented using Qt or another native toolkit?
- pdimitar 2y ago
  Wish I could but many people gave up and started using Electron due to employability. And we're stuck with crappy laggy UIs. I remember the MirandaIM multi-messenger from 20+ years ago very fondly... 50MB RAM usage and I was signed to 4 services, on a computer that my smartphone today can emulate 16 of, simultaneously, and it was still running faster than you can blink. Ehhhh, good times. Electron/JS is a herd just running in one direction, personified. The fact that something is popular does not imply quality, not at all. Most of the time it implies that everybody settled on it and does not want to hear otherwise for various reasons (in this case: money, as employers are never going to give you the requisite time to build stuff with Qt or others).
  - foldr 2y ago
    It could be that Qt would work better and no-one is using it for the sorts of reasons that you mention. But I think the more plausible explanation is that no UI library can compete with what the browser offers anymore. This would hardly be surprising. The person hours invested in HTML+CSS rendering vastly exceed those invested in Qt or any other UI lib. The kind of argument you're making would be much more convincing if there were relevant examples of Qt-based apps that provided a superior user experience to the Electron apps you're criticising. I don't personally find Electron apps laggy in general. VSCode is very responsive, for example.
    - pdimitar 2y ago
      Yeah VSCode is fine, I agree. But as mentioned above, if one can screw up their Electron app to be as laggy as Slack then the tech is not good. I stand by that statement. > The kind of argument you're making would be much more convincing if there were relevant examples of Qt-based apps that provided a superior user experience to the Electron apps you're criticising. That's arguing in circles and it's the chicken-and-egg problem. Toolkits like Qt get less and less mindshare because Electron is desired and is encouraged by employers. I can't speak for Qt in particular btw, just using it as an example here, but my point is that it could be the best UI toolkit ever but since it takes a little more time to spin up an app with it then the business will want you to not use it. Hence, I can't show you those Qt apps. I feel that in these discussions people just blindly trust popularity to be an indicator of quality. I have a huge problem with that mindset and my career has seen the exact opposite, many times. Hence my comments. And if you want to take away just one thing from our discussion, it's this: please don't mistake Electron's popularity with the idea that Electron is the best UI toolkit.
      - rubymamis 2y ago
        One obvious reason why Qt is less popular is the ability for companies to deploy web apps (non Electron, but in the browser). Many end users expect a desktop/mobile app to also be accessible using the browser. I'd argue that QML is an order of magnitude easier to develop than any other web frameworks (yes, you do have to get familiar with it, and if you made some apps before you could re-use some essential, battle-tested components). I hope to maybe share/sell some of mine some day. I'm not sure what to answer regarding the browser experience. WASM isn't really there, isn't it? I haven't had a chance to test it on my own apps yet tho. I recently had a thought that maybe that Qt Company should also target HTML/CSS/JS generation of a QML file. Another, more interesting thought would be for browsers to be able to process and render QML files natively (but that won't happen without substential market share).
- rubymamis 2y ago
  I'm building a chat app - well, a client for LLMs using Qt (QML + C++). It's highly performant with beautiful animations: https://rubymamistvalove.com/client.mp4 https://rubymamistvalove.com/client.mp4 I also created a native block editor (like Notion's) in QML and C++: https://get-notes.com https://get-notes.com I really hope that I can show that Qt with QML is a viable alternative to the inefficient resource hogs that are Electron/web apps.
DecoySalamander 2y ago
I use Discord daily and can't really call it slow and laggy, it feels adequate if anything. Can't really comment on Slack and Teams - I've obviously used both, but haven't been a heavy user of Teams and never was in a large "corporation-wide" Slack instance. I have, however, been a heavy user and developer of a Slack competitor. Not surprisingly, it had a lot of problems, but most of them stemmed from a) clumsy handling of megabytes of chat logs, b) a codebase that grew organically out of a startup project and needed a major rewrite, c) misallocation of resources (for the longest time, everything Electron-related was handled by a single developer in a satellite office). In my opinion, we would have had the same performance issues and bugs if it had been developed in any other language. We actually had some Qt apps that we deprecated and rewrote in JS as part of the main client - there was no user-noticeable performance drop, but significantly fewer crashes.
- pdimitar 2y ago
  ...OK? It was already mentioned that people can do better apps with Electron than others. Not surprising. My objection is that the possibility to make laggy and bad apps exists. It should not exist. As for what problems a Slack competitor faces, well, I am not interested. That's the dev team's problem and not mine. I want a lagless Slack.
  - DecoySalamander 2y ago
    > the possibility to make laggy and bad apps exists. It should not exist I see. Then the only way forward is to stop all software development altogether and enjoy memories of apps that we used 20 years ago when we were much younger, and fantasies of apps that we could build with newly acquired wisdom, but will not.
    - pdimitar 2y ago
      Funny, still not what I said. Progress is way too slow and blindly follows local maximii. That's not OK. That's the part I am expressing displeasure with.

ogoffart 2y ago

It's also possible to use JS (or TypeScript) on the desktop, without having the need for a browser or a webview. That's for example what we're trying to do with Slint https://slint.dev https://slint.dev Then you get the good part of javacript for your application logic, without the bloat and attack surface of a browser.