Energy usage is not fixable, without fundamental changes to how Electron -- in particular the JS engine underlying it -- works.
Sharing a runtime in memory is a good way to amplify problems associated with memory fragmentation and also cause instability in one application to affect other applications.
Another thing that affects JS' suitability to some classes of problems is the fact that all numbers are IEEE 64-bit floats. No integer arithmetic at all. While FP is much faster than it used to be, it's nowhere near as fast as integer arithmetic. Thus, even if a Sufficiently Smart JIT could eliminate all other JS overhead, even calculating offsets into the text buffer in Atom would have a significant disadvantage performance-wise. (And that happens more than you might think: consider syntax highlighing, as well as layout and navigation.)
At the end of the day, JS is unsuitable for writing well-behaved desktop applications if only because of the energy impact. If it were a constant overhead then the argument could be made that it's more suitable for large desktop apps, but it's not: it scales up with the complexity of the problem. It starts out bad, which makes for a markedly worse experience for users when the app is small/special-purpose/utility-like in nature, and then gets worse when the app is complex enough to have logic that might not finish in a small fraction of a second.
Even the Atom project has had to accept reality here: 1.19 includes an experimental native-code implementation of the core text buffer!
Because JS is just the wrong tool for the job. And while the Atom project might blunt the worst of the problems by dropping down to C/C++ for the most performance critical pieces, that energy impact overhead still remains.
In contrast, Dropbox on OSX/Windows is written largely in Python (using wxPython/PyObjC to access the native UI system), and suffers no such energy impact problems while still maintaining a high degree of portability, a smaller install size.
The bottom line here is that when you use Electron you are trading your customers' resources for a reduction in development overhead. To the extent that that matters to your customers you are choosing to create an extra barrier to adoption. On mobile, this is already a sensitive enough point for people to scream bloody murder when a developer gets it wrong (see: Facebook having to gut their app). On laptops I only see it becoming more of an issue as Apple and Microsoft are putting more and more emphasis on battery life -- both in enabling well-behaved apps to be better behaved (e.g. Timer coalescing on macOS) and by identifying and calling out badly behaved apps (energy impact).
It is unreasonable for someone to come on here and whine about how unfair it is that their app is being judged by how the app actually behaves or even by a really good proxy signal for how it must behave.
This is your potential and actual customers providing you feedback. Maybe you should listen.
Also, I should note it's not just the JS engine: Chromium itself still doesn't play nice with things like timer coalescing. Until and unless that is fixed, Electron remains a significant liability in terms of user experience.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Energy usage is not fixable, without fundamental changes to how Electron -- in particular the JS engine underlying it -- works.
Sharing a runtime in memory is a good way to amplify problems associated with memory fragmentation and also cause instability in one application to affect other applications.
Another thing that affects JS' suitability to some classes of problems is the fact that all numbers are IEEE 64-bit floats. No integer arithmetic at all. While FP is much faster than it used to be, it's nowhere near as fast as integer arithmetic. Thus, even if a Sufficiently Smart JIT could eliminate all other JS overhead, even calculating offsets into the text buffer in Atom would have a significant disadvantage performance-wise. (And that happens more than you might think: consider syntax highlighing, as well as layout and navigation.)
At the end of the day, JS is unsuitable for writing well-behaved desktop applications if only because of the energy impact. If it were a constant overhead then the argument could be made that it's more suitable for large desktop apps, but it's not: it scales up with the complexity of the problem. It starts out bad, which makes for a markedly worse experience for users when the app is small/special-purpose/utility-like in nature, and then gets worse when the app is complex enough to have logic that might not finish in a small fraction of a second.
Even the Atom project has had to accept reality here: 1.19 includes an experimental native-code implementation of the core text buffer!
Because JS is just the wrong tool for the job. And while the Atom project might blunt the worst of the problems by dropping down to C/C++ for the most performance critical pieces, that energy impact overhead still remains.
In contrast, Dropbox on OSX/Windows is written largely in Python (using wxPython/PyObjC to access the native UI system), and suffers no such energy impact problems while still maintaining a high degree of portability, a smaller install size.
The bottom line here is that when you use Electron you are trading your customers' resources for a reduction in development overhead. To the extent that that matters to your customers you are choosing to create an extra barrier to adoption. On mobile, this is already a sensitive enough point for people to scream bloody murder when a developer gets it wrong (see: Facebook having to gut their app). On laptops I only see it becoming more of an issue as Apple and Microsoft are putting more and more emphasis on battery life -- both in enabling well-behaved apps to be better behaved (e.g. Timer coalescing on macOS) and by identifying and calling out badly behaved apps (energy impact).
It is unreasonable for someone to come on here and whine about how unfair it is that their app is being judged by how the app actually behaves or even by a really good proxy signal for how it must behave.
This is your potential and actual customers providing you feedback. Maybe you should listen.
Also, I should note it's not just the JS engine: Chromium itself still doesn't play nice with things like timer coalescing. Until and unless that is fixed, Electron remains a significant liability in terms of user experience.