Live data from Hacker News

The State of Atom's Performance

blog.atom.io

21–30 of 293 posts

Re: The State of Atom's Performance

#21
post #4
post #2

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.

And Electron’s are written in C++, so I’m unsure what your point is.

Re: The State of Atom's Performance

#23
Performance is the reason I switched from Atom to Sublime Text in the first place. I was annoyed that it took seconds to start, and even then it felt sluggish. At some point I might give it another go but for now Sublime Text suites my needs perfectly, even if it has a smaller package ecosystem than Atom.

Re: The State of Atom's Performance

#24
I do go back to Atom often because of a few details that I like better over VS Code, but it's a lost cause, and reading this proves it.

Who 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

#26
post #3

>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 just started writing a GAE Python app, and I needed a good, free editor for my Mac. I chose vscode, and it's been superb. Hitting shift+cmd+p for any command, the python tooling, and the default keyboard bindings are great.

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

#28

I 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…

Firstly, I agree with you! I like the philosophy that "Production should be as boring as possible."

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
post #3

>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…

Also isn't the majority of Sublime Text written in Python which in my experience is slower than JavaScript.
Post reply on HN