That's odd. I am replying here, although there are a number of atom-is-slow comments throughout the thread. I don't find it to be slow with normal-sized sourcefiles. By "normal", I mean less than, say 5kb of text per file. Big files I do avoid in atom, but they tend to be rare in my codebases.
I don't use a ton of plugins, just tag matchers, minimal, and linters. I do all my build tooling (gulp for js/web dev, mavensmate for salesforce, etc) outside of atom, so maybe that helps.
Of course, the only real benefit I feel over sublimetext is in plugins. Linter support in atom is (IMO) better than ST. For actual code editing, they're all similar enough once you learn key bindings and whatnot.
I will say: being proficient in vi means I can work on ARM devices (Chromebooks with crouton), because neither ST nor atom work on arm. Yet, from the atom perspective, or ever from the ST one, which is the other reason I like the atom project. Loftier, FOSS goals.
>I don't find it to be slow with normal-sized sourcefiles. By "normal", I mean less than, say 5kb of text per file.
5 thousand bytes is pretty small. It is 122 lines of text if we use the average bytes per line of some code I have lying around (Emacs Lisp, exactly one byte per character, lines limited to 80 characters). For comparison, the average lines per file in the code I have lying around is 233.
When was the last time you tried it? It is plenty fast for me now. Original load times were 7 to 10 secs and are now under 2 secs for me, with a zillion packages to load.
Oh, I open it up about once a week. It's not that much slower than, say, Sublime Text, without any plugins installed. However, I like to load up my text editors with IDE-like affordances. I also wanted to experiment with a bunch of Facebook languages so I thought I'd try Nuclide, which basically made Atom unusable that last time I tested it.
It's a shame that it doesn't work better, because it's truly a great idea. I have some faith that the performance will improve but there is a limit and I'm almost certain that that limit is below that of editors that render natively. Now, if they started supporting a statically typed JS like TypeScript or if they did something like restrict the plugin architecture to a simpler DSL and the theming language to be a smaller subset of HTML, that might improve things, but it would also no longer "just work" for web developers wanting to write plugins for it.
Edit: Also if WebAssembly becomes a widespread thing it would help performance greatly.
> I thought I'd try Nuclide, which basically made Atom unusable that last time I tested it.
I found the same. I just tried nuclide again, which I do once a month or so, and it basically rendered Atom useless.
> I have some faith that the performance will improve but there is a limit
I used to argue the same thing, because it is built on the DOM, but after talking to a few of the Atom developers and a guy from Google at a conference I have new hope. The google guy said in a talk that Google was adding an API that allows javascript to go around the DOM. You will be able to render text into an existing DIV directly without triggering the DOM. This was specifically to allow things like atom to display and scroll text fast.
So there are clever people working to fix speed problems. I personally am not seeing speed problems even with 30 or 40 plugins. I think the breaking point was 1.0.
+1. I normally work on small-ish codebases, and even then Atom just feels sluggish. It's performance with large files is laughable - normally just crashes/stalls - and the nicer ui does not make up for it. Adding plugins to make the development experience great for my workflow just ends up slowing it down :(
I like to try it every so often but end up going back to Sublime Text 2.
I don't use a ton of plugins, just tag matchers, minimal, and linters. I do all my build tooling (gulp for js/web dev, mavensmate for salesforce, etc) outside of atom, so maybe that helps.
Of course, the only real benefit I feel over sublimetext is in plugins. Linter support in atom is (IMO) better than ST. For actual code editing, they're all similar enough once you learn key bindings and whatnot.
I will say: being proficient in vi means I can work on ARM devices (Chromebooks with crouton), because neither ST nor atom work on arm. Yet, from the atom perspective, or ever from the ST one, which is the other reason I like the atom project. Loftier, FOSS goals.