Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app And yet Emacs is fast, hmmm.
Emacs' display engine, input handling, etc., are written in C.
The State of Atom's Performance
21–30 of 293 posts
Re: The State of Atom's Performance
#22Re: The State of Atom's Performance
#23Re: The State of Atom's Performance
#24Who cares about start-up time? I only open the thing once/day. Same thing for large files: it's a edge case. Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal.
What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
What they'd need is a huge architectural overview, and the fact that they're showing off how much they're optimizing proves that they'll never be as performant (or even close) as they'd need to.
Also weird that they blame extensibility. Emacs does it, Firefox does it, Chrome does it, and most importantly VS Code does it. I'm sure it's not easy, but it's done by other projects.
Too bad, because the UI is very nice, package management is very good, as well as not having to edit JSON files for settings (which sure I can do, but I see no added value and I'm lazy).
Re: The State of Atom's Performance
#25Re: The State of Atom's Performance
#26>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly. Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it d…
I wouldn't recommend switching away from Visual Studio to vscode, for .NET work, but for a new language/project, it's a great choice.
So now I started editing an asciidoc file in vscode on windows, since it's a productive text editor, but the back, forward, previous, next, kill, killall key bindings are all Windows-like and not Emacs/Unix like. Fortunately, it's was easy to add the six bindings in their fancy settings cascade text editor.
Re: The State of Atom's Performance
#27Re: The State of Atom's Performance
#28I am not badmouthing JavaScript or bandwagoning on the "Electron is the devil. Long live native apps!" But I've been wondering more and more, especially through my own experienced biases at work: how much of the, "we chose x because y and z" is retroactive justification for the simple truth: "I wanted to use the technologies that make me enjoy my job." I often have to fight with myself to pick the right tool for the…
That being said, using tech that makes you enjoy your job will help you be more productive and potentially attract enthusiastic developers.
I feel there's probably a balance (as in all things) between boring production/exciting development - but I don't feel I hear that discussed often enough.
Re: The State of Atom's Performance
#29>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly. Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it d…
Re: The State of Atom's Performance
#30The guy is amazing.