what's wrong with electron?
I keep on seeing people complaining about Electron here, but it's brought about an age of hundreds of thousands of applications that have compatibility across OS' to do very specific tasks.
I just feel that the ~80MB memory usage and large file size (30-60MB) is inconsequential in modern computing.
Performance in Electron-based editors (e.g., Atom) is horrible. When you're used to vim or fast GUI-based editors like Sublime, even typing in Atom feels sluggish. That's not even talking about loading large files, search-and-replace operations, multiple cursors, etc.
Example stats: https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
Resource usage can be justified if the that resources is used toward something meaningful. C is "slower" than assembly, yes; however both assembly can be inlined into C, and magnitudes more can be done with C at near-assembly speeds.
I develop in C/C++/Python mainly and in some other languages for fun and curiosity. Python is easy, but it's not as performant unless the underlying library is native, hence nobody is using it if it can't obtain very high performance in my field (scientific computing, HPC, and related areas).
Actually, writing a low performance GUI is pretty hard since most of its cycles are idle. If you can write an application with a GUI which slow to respond to low-complexity, common tasks (naive text editing, input, menus, moving windows), something is very, very wrong (to be clear, GUI can trigger resource intensive background tasks, but that's not what I'm saying).
This is an over exaggeration, and quite a large one. Facebook just released information on the average memory usage of "nuclide" (their Atom editor bundled with a metric ton of plugins which use quite a lot of memory) to be around 600mb. And that's not indicative of a "normal" Atom user (if there can be such a thing).
I personally have currently 5 windows open in atom, with about a combined 40 tabs, and about 30 plugins installed, and my instance is using 360mb of memory right now across all processes. And those windows have been open for about a week now.
And that Atom instance is running a lot of what your Eclipse instance is running. Linters, autocomplete, code analysis tools, CI server integration, a webserver for serving up my application in the editor, a debugger that links the live preview in the editor with the code in the editor, and a ton more.
Switching to something which uses a few hundred less MB of RAM for a fraction of the capability would be a monumentally stupid thing to do, as Atom makes me significantly more productive than any other editor I've tried has ever before.
There are a lot of problems with Electron, but memory usage isn't one of them any more. It can be, just like with any language/platform, but it's not "inherent" to the technology.
* 1 front-end react monorepo which contains a handful of front-end projects with about 50k LOC of js files only across them all
* 1 backend node.js projects with about 7k LOC
* 2 npm packages that I'm working on. One that's like 300 LOC total, and another that probably hits around 1k (haven't measured, just a guess)
* 1 go project that I'm hacking on in my spare time, but I just keep the window open because why not? this has about 1k loc.
It looks like you're a web developer, I'm not. I develop at the system level, and for development scenarios Atom is nowhere capable as Eclipse, and seriously that's OK. Every IDE has its niche. I used atom as a pretty text and script editor for my needs, but its auto complete capabilities left too much to be desired for me.
Honestly, maybe atom was not optimized for better memory usage before. Maybe there were memory leaks. Maybe my build was buggy (I used an official deb package BTW), or maybe he tested a buggy version, but these problems were (or are) real for some other people, and they may have been solved or not; but I'm neither the only, nor the last people who talked about excessive memory usage of atom.
I loved atom when it first came out. I tried to migrate to it, but it has burned me with its radioactivity. So I returned to my dark corner under Eclipse to work and recover.
Atom has made significant strides in the last year reducing that overhead, but the 800 mb from that article was a bug, and was if i recall fixed in the very next version, reducing the total memory usage from opening that large xml file to basically nothing. Even your article shows that it started with a ~250mb memory usage, but the article didn't go into detail about what happens when you open a ton of files (the memory usage only increases a small amount with each file). The overhead is large, but it's fairly static. And judging a program by it's baseline memory usage when using it for it's most trivial tasks seems silly. It's like complaining that your OS takes a minute to boot up just to edit a text file, when VIM can start up in a hundred milliseconds!
>I develop at the system level, and for development scenarios Atom is nowhere capable as Eclipse, and seriously that's OK.
I completely agree! I just hate when there are perfectly valid problems and issues with a technology, but people ignore them and jump on the bandwagon of a non-problem.
Just like how there was a time when Emacs was a laughing stock for being so resource intensive, things improve, bugs are fixed, programs are optimized, and hardware gets more capable. Judging programs by what they once were is an easy trap to fall into, but it's not helpful for anyone.
Same for me. I didn't intend to 'bash' atom and electron. I just wanted to point some problems with it. If my style sounded like bashing, I'm sorry, it was unintended.
> Atom has made significant strides in the last year...
Honestly, I may give it another shot, as a semi-IDE rather than a complete replacement to my Eclipse setup. I love to explore new applications and see what they do right and where they lack.
>I may give it another shot...
If you do, I recommend doing a complete uninstall of it, delete your `~/.atom` folder (or `%USERNAME%\.atom` on windows), and reinstall from scratch. I'd also recommend trying out the new-ish "Atom IDE" set of plugins [0] which works fantastically for languages that have an IDE plugin (javascript/typescript, C#, Java, PHP, and some still-kinda-early-stage ones for Go, C++, and rust right now). I don't know what it is about the "IDE-*" packages, but they don't install well to "aged" setups, and they don't uninstall well either. If you don't like them, i'd recommend wiping clean again before moving on... (all the customizability in atom comes with the major downside of needing change-management in your goddamn editor...)
I'll freely admit that the amount of time I sunk into getting my atom install the way I like it probably approaches "not worth it" levels (I tend to do that with any editor!), but spending an hour or 2 looking for and playing with packages really pays off now.
Java will probably always be better off in a "made-for-java" IDE, but i've done a fair amount of C++, PHP, and Go work in Atom and it's a breeze.
I sometimes make the same thing. It's perfectly OK, we are all human. We all have some technology we like to protect as our only child (my soft spot is low-level & high performance tech). The key is to be able to recognize one's reaction and tune it little by little. I had my share in both sides of a flamewar and I'm very well done in that respect. BTW, I didn't feel like you did. I just wanted to say we sometimes overreact, and even if we don't project it to otherside or just to outside, we can learn from the experience.
> If you do, I recommend doing a complete uninstall of it...
I've completely removed every atom related folder from my home folder some time ago. I'll install the latest .deb package and progressively experiement with it. I won't tie anything important to that setup, so it will be an experiment bench for me.
I'm using Eclipse for ~10 years, so I know the effort you put into setting it up. It's always worth it, don't worry. I maintain three eclipse installations (home, office, laptop) and they sync their settings over Oomph. So when I improve something in one, all three benefits :) When you use something for a very long time and set it up to your liking, it feels like home. :)
Meanwhile, my very well kitted-out MacVim is currently cruising along at 35.9MB.
Quantity over quality seems to be the recent trend.
The general reason for the performance of C/C++ apps is that the language forces you to care about your memory usage. The lack of a garbage collector ensures that you think twice about what memory you allocate and free. Someone with a background in c/c++ will write efficient electron apps. Their past experience ensures that they reflexively write good code.
I wrote an electron based music player that uses less memory than a native player developed in c# that i wanted to replace. I spend an hour reviewing and profiling every feature that I add to ensure that i am not wasting memory. And it shows.
People need to understand that it is not the platform that is slow. It is the stupid code that you write without a thought that is the problem.