> But this is such poor logic.
No, it’s not. It’s at most a trade-off. Some developers will doubtless make this their hill to die on, but I suspect it really has nothing to do with performance or battery life, and it’s likely motivated by resistance to web technologies being used on desktop vs what they’re used to.
Also I’d like to see some actual battery life benchmarks for electron, because I don’t imagine that it’s a huge deal, but benchmarks would prove the matter. It also ignores actual desktop users or users who just use mains power all the time.
Re:Electron 4.0.0
by spiralganglion on Friday December 21, 2018 @12:34PM
(#18734846)
If you’re on a Mac, open up activity monitor and watch which apps use the most energy. For me, the energy used by Atom, Slack, and Chrome is vastly higher than the energy used by other apps (inc. Safari loaded with tabs). It’s possible to make an energy efficient Electron app — you just need to aggressively shut off event loops when there’s nothing to update, which is hard so most app (and site) devs don’t bother. (I make complex animations on the web, so I’m hyper attuned to perf and energy use)
That and check if the window is hidden, which was improved a bit in this release.
I’m curious, do you compile anything to asm.js?
Re:Electron 4.0.0
by spiralganglion on Friday December 21, 2018 @07:11PM
(#18737923)
Not yet, though I'm keeping my eye on WASM and will pursue it if the need arises. The sort of work I do has relatively little overhead from the JS, and is mostly bottlenecked by rendering (SVG, mostly). WASM wouldn't help my load/parse times since I rarely ship more than a few Kb of JS, and it wouldn't help my per-frame times or latency because I'm usually done the JS part of the frame in around 1ms.
But this is such poor logic. We can notice these things, while regular users just suffer not knowing why their battery drains so quickly, unable to pinpoint the problem.