4 ms·
> So you are willing to trade ~1GiB of your RAM and ~5% of CPU cycles just to be able to send/receive some text messages? Yes. Also, I'm curious, do you find t
by Mavvie 6y ago
> So you are willing to trade ~1GiB of your RAM and ~5% of CPU cycles just to be able to send/receive some text messages?
Yes. Also, I'm curious, do you find the webapp forms use measurably less resources than the electron version? I would've imagined they're pretty close (with Electron possibly even being lighter than a full browser tab), but I am not confident and could be completely wrong.
> Imagine using VSCode, Discord, Slack, Matrix, Spotify, some markdown editor and now you have 6 browser instances chipping away your machine resources
I, and surely tons of others on this forum, am doing this right now without issue.
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.
- bayindirh 6y ago> 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.
- qbasic_forever 6y agoThere 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).
- bayindirh 6y ago> 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.
- ducktective 6y agoThe reasoning is, since those are "web"-apps at the core, I saw no reason to complicate my OS package manager with a chrome-instance (bar VSCode). The whole install-use-update could be replaced by opening a tab. I've used Postman as a desktop app and the performance was subpar.