> I, and surely tons of others on this forum, am doing this right now without issue.
I personally run Teams, Spotify, Evernote and Discord, but I close them as soon as finish working with them. So without issue is a bit of a stretch. Also These applications glitch in a funny, agonizing and obscure ways. They are non-deterministic blobs and this is not good.
> Sure it's not perfect, especially if you're on battery, but most of the time it just doesn't matter to almost all of their user base.
Actually, when computing is moving on portables in an ever increasing speed, this sounds bad. "It's a nice application, but it just kills your mobility. It's not important anyway, eh?"
I don't think the approach of "we have a lot of processing power and its processor is efficient anyway, so let's abuse this" is a good way to approach software development.
There is enormous pressure on web engines to improve efficiency and decrease battery/power spend. With browsers and JS sandbox VMs they are much better equipped to actively manage and spin down idle tasks. Folks get 20+ hours of battery now on M1 macs running tons of Electron apps like Slack, Discord, VSCode, etc. all at once.
The reality is it's far, far easier to write a bad Qt app that sits in busy wait loops locking up an entire core while refreshing UI and destroys your battery (this is a knock on complex native app development, not Qt).
> There is enormous pressure on web engines to improve efficiency and decrease battery/power spend.
Yes. However, these efficiencies are not always translate to better Electron or WebApps on desktop applications.
> With browsers and JS sandbox VMs they are much better equipped to actively manage and spin down idle tasks.
If your code doesn't allow these idle tasks to spin down, all this work is effectively moot.
> Folks get 20+ hours of battery now on M1 macs running tons of Electron apps like Slack, Discord, VSCode, etc. all at once.
This is possible because of the process suspension capabilities of macOS. Not efficiencies of the applications themselves completely. Evernote is the 6th most power hungry application on my M1 MacBook Air, First two is Zoom and Skype. Third one is Safari. I run Teams and Discord only on my desktop, so I've no 12hr power statistics for them for now.
> The reality is it's far, far easier to write a bad Qt app that sits in busy wait loops locking up an entire core while refreshing UI and destroys your battery (this is a knock on complex native app development, not Qt).
Qt's QML simplifies this stuff tremendously. You can write a whole UI in Qt in five lines with QML, without thinking about any of this stuff, while keeping everything native and nice.
I personally run Teams, Spotify, Evernote and Discord, but I close them as soon as finish working with them. So without issue is a bit of a stretch. Also These applications glitch in a funny, agonizing and obscure ways. They are non-deterministic blobs and this is not good.
> Sure it's not perfect, especially if you're on battery, but most of the time it just doesn't matter to almost all of their user base.
Actually, when computing is moving on portables in an ever increasing speed, this sounds bad. "It's a nice application, but it just kills your mobility. It's not important anyway, eh?"
I don't think the approach of "we have a lot of processing power and its processor is efficient anyway, so let's abuse this" is a good way to approach software development.