20 comments

[ 2.7 ms ] story [ 46.2 ms ] thread
I wonder how noticeable the recent performance improvements really are.

I have been on VSCode for a while but might give Atom a try for a change, and see how much it has evolved.

Stick with VSCode. It's better in my experience.
I prefer VSC too, but no harm in trying out the improvements in Atom.

There's one feature/plugin in Atom that I wish VSC had, which is browser-plus. I haven't found anything comparable in VSC, which is a shame as it'd be useful when iterating through website designs.

I love Atom, and use it as my main editor, but it's many times slower than Sublime Text.

I hope but doubt Electron will ever get near native in terms of performance.

Yeah, even the 2x claimed is nothing compared to sublime.
I'm curious if you have tried VSCode? It seems significantly faster than Atom and is built on Electron (and I think an Atom base).
Microsoft has an extraordinary amount of in-house talent when it comes to IDEs and performance, and it shows in VSCode.

The difference in responsiveness between the two editors is stark and it's a primary reason I never use Atom anymore (though the increasingly sophisticated intellisense and integrated CLI tools is what's kept me in VSCode).

Omg these three comments are the same in every atom release. It's not a bad thing, just funny. 1. Atom is slow. 2. Have you tried VS Code? 3. Microsoft has a small but effective team developing VS Code, well done to them.
Every frigging time. This pattern never ceases to amaze me.
Idk but I remember reading somewhere that VSCode is written by a 5 man team?
Isn't Sublime Text one guy..?
I have.

There are a few things I like about Atom that keep me from switching despite its speed.

I just wish it was native, or at least a little faster. It's got bugs, too.

Webassembly and Servo might big boost when available.
is it faster than VSCode now?
Unlikely, especially with plugins.
Large File Performance graph suggests that it will open a 7MB file in 300ms~350ms yet it still opens a 7MB utf-8 encoded file in 6000ms.
Is this on 1.14-beta0? If so, please open an issue. We now do a lot of text layout computation lazily, but currently, it's very easy for a third-party package to accidentally force the entire text layout to be computed immediately via an API call.
Yes, Atom isn't the greatest across a number of performance metrics, but if my experience it irresplacable for:

1. markdown support is top notch

2. proto-repl[1] in clojure is amazing and only available on Atom.

[1] https://atom.io/packages/proto-repl