What the f*** are you talking about? Do you have any idea how much work has gone into both Atom and VSCode by hundreds, perhaps thousands of engineers? Surely some of which are more accomplished than you.
Not only that, but I would classify neither of those products as "text editors", and more along the line of extremely extensible IDEs, Atom for example has some 2000 more plugins than Sublime.
Finally here is a list of other applications that run on Electron, some of which were mentioned in this article and certainly more diverse than 'just a text editor.' If you can't contribute more than a strawman argument with no facts, why say anything at all?
Despite a richer ecosystem of plugins, Atom is fundamentally similar to Sublime. It's also significantly slower, consumes dramatically more memory, and is dramatically worse for battery life. The cases where it's noticeably slower, it's often so much slower that it is effectively incapable of performing the task at all. (Yes, opening and working with a million-plus-line file is a thing I do often enough that having to switch to vi or some other editor for it is a significant drawback.)
Further, I have yet to encounter any set of plugins in Atom that are even close to being compelling enough to justify giving up a large fraction of my on-battery time.
Definitely no arguments about power consumption, and will concede that it does fall over on really big files - I will occasionally accidentally click on a compiled JS file or something and immediately regret it because Atom slows to a crawl. Come to think of it, I might write an extension for that.
I'm happy to have a discussion about how Electron can be improved or what pain points are for developers. What I cannot stand are ad hominem attacks on the language or the developers that contribute, simply because somebody has had a bad experience on open-source software that they are using for free.
For instance, I would really love to see a shared runtime among all apps. Sure targeting your own specific runtime by bundling it in is great for compatibility because you always know what the behavior will be; but I would argue for the vast majority of use cases it is not necessary. This would potentially save on storage and a bit of memory due to all of them sharing the master process.
FWIW, VSCode is becoming very good - even with non-crashing for large files, though 1M lines is quite a lot and YMMV :) I know that they don't "render" text that is not within the viewport, but I'm curious if there could be further optimizations by just tracking a line position in memory and then streaming parts of the file in on demand. Of course that breaks search.. hmm.
As another example: the idea of keeping a window of the file in memory is not a bad idea -- if only for the sake of search. The best way to handle it is using mmap. However that's going to be a dangerous thing to try and expose to JS if the runtime uses a copying garbage collector. So instead you're going to have some very... interesting... shenanigans you need to go through to make that possible. And you're going to need to break out of JS into native code to do it. And if you forego mmap then you're going to be fighting a losing battle, with a ton of wrong ways to achieve the goal -- but very few right ways.
Using a sliding window for actual editing is just trading increased I/O for reduced memory usage. It's not a clean win, just a different tradeoff.
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.
What the f*** are you talking about? Do you have any idea how much work has gone into both Atom and VSCode by hundreds, perhaps thousands of engineers? Surely some of which are more accomplished than you.
Not only that, but I would classify neither of those products as "text editors", and more along the line of extremely extensible IDEs, Atom for example has some 2000 more plugins than Sublime.
Finally here is a list of other applications that run on Electron, some of which were mentioned in this article and certainly more diverse than 'just a text editor.' If you can't contribute more than a strawman argument with no facts, why say anything at all?
electron.atom.io/apps/
Despite a richer ecosystem of plugins, Atom is fundamentally similar to Sublime. It's also significantly slower, consumes dramatically more memory, and is dramatically worse for battery life. The cases where it's noticeably slower, it's often so much slower that it is effectively incapable of performing the task at all. (Yes, opening and working with a million-plus-line file is a thing I do often enough that having to switch to vi or some other editor for it is a significant drawback.)
Further, I have yet to encounter any set of plugins in Atom that are even close to being compelling enough to justify giving up a large fraction of my on-battery time.
Definitely no arguments about power consumption, and will concede that it does fall over on really big files - I will occasionally accidentally click on a compiled JS file or something and immediately regret it because Atom slows to a crawl. Come to think of it, I might write an extension for that.
I'm happy to have a discussion about how Electron can be improved or what pain points are for developers. What I cannot stand are ad hominem attacks on the language or the developers that contribute, simply because somebody has had a bad experience on open-source software that they are using for free.
For instance, I would really love to see a shared runtime among all apps. Sure targeting your own specific runtime by bundling it in is great for compatibility because you always know what the behavior will be; but I would argue for the vast majority of use cases it is not necessary. This would potentially save on storage and a bit of memory due to all of them sharing the master process.
FWIW, VSCode is becoming very good - even with non-crashing for large files, though 1M lines is quite a lot and YMMV :) I know that they don't "render" text that is not within the viewport, but I'm curious if there could be further optimizations by just tracking a line position in memory and then streaming parts of the file in on demand. Of course that breaks search.. hmm.
As another example: the idea of keeping a window of the file in memory is not a bad idea -- if only for the sake of search. The best way to handle it is using mmap. However that's going to be a dangerous thing to try and expose to JS if the runtime uses a copying garbage collector. So instead you're going to have some very... interesting... shenanigans you need to go through to make that possible. And you're going to need to break out of JS into native code to do it. And if you forego mmap then you're going to be fighting a losing battle, with a ton of wrong ways to achieve the goal -- but very few right ways.
Using a sliding window for actual editing is just trading increased I/O for reduced memory usage. It's not a clean win, just a different tradeoff.
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.