Nope, completely wrong. I have a 32GB i7-4790K at around 4Ghz or so, and Atom is a complete dog. The painful truth is that a webview is never going to beat a native app at this kind of task.

It's not a vocal minority. Atom is painful to use compared to, say, Sublime.

I suspect that both are right. Some people are having issues and others are not. I don't seem to have any lag at all when typing even with multi megabyte size files. Maybe you could give some more details into exactly what actions were slow for you and what types of files you were editing.

Actually, thanks to innovations in Mozilla's servo, the web may actually become faster than native.

Speak for yourself. I haven't had any performance problems with Atom for quite some time with similar hardware.

You expect me to believe that with those specs Atom really runs like a 'complete dog'? The fact you also mention Sublime too really just tells me that your opinion was biased from the start. Finally, JIT compiled languages can be just as fast as native, simply because they can optimise to your hardware specs. You are getting mixed up as to why things are the way they are; JavaScript is a dynamically typed language, so the engine doesn't know AOT what types have what members, so this can cause a slow down compared to statically typed languages. BUT any JavaScript engine worth it's salt quickly figures the stuff out on startup so it's not a problem, as long as you don't use too many dynamic tricks that it can't optimise.

I don't think it's a JIT vs native issue, it's more likely from native UI components vs DOM. I'm sure JS as a language is plenty fast enough, but the DOM adds overhead that kills that. But this is just speculation on my part as I've barely tried Atom.

For the record, I have the same CPU as him but with 16GB of RAM and Atom is obnoxiously slow for me.

Never used Sublime, but I am biased towards Vim ;-)

You should believe them and others on here. Atom is slow. No way around it.

If you or others say that it's fine, then you're suffering from Stockholm syndrome, having been taken in to the cult of Atom.

>If you or others say that it's fine, then you're suffering from Stockholm syndrome, having been taken in to the cult of Atom.

Can we please stop accusing each other of malicious intent? I can't believe there are people on both sides of this argument that can't see that the other could have a different experience.

I'm just starting to use it today on a large code base, and it's been fine. Only have vim and go-plus plugins installed. I would guess plugins are what's slowing most.

Did you not read my original post? I only just downloaded Atom for the first time.

Seems to me like you're suffering from "I can't replicate it therefore it does not exist and everybody else is either lying to me or a complete idiot."

You haven't actually called anyone out as liars or idiots, but your lack of belief of what they are communicating to you and the tone (from what I can gather) of your responses speaks for itself (whether or not that was your actual intention).

So, no "real world" assortment of plugins for today's multilingual developer? Is that a valid assumption?

Broad statements like that make you sound like another editor's fanboy.

> went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance.

Pfft, 1000 lines of code? If Atom couldn't handle tiny files like that, you couldn't even call it an editor. Try working with a 10-20k+ line file (very common for me when looking at compiler output) and your heart will skip a beat when you realize that you had unsaved changes in another file before opening that file, because the whole program locks up for about 5 seconds trying to apply highlighting. I have to use sublime text for those files and watch where I click in Atom because of this.

I'm using a very recent quad core i7 MBP with 16GB ram and an SSD, absolutely not my computer.

Ok sure, I opened up a 1000 SLOC file and copied until it was a 20,000 SLOC file, and performance was still fine. So I made it a 60,000 SLOC file. This time there was a small drop in perf as the editor caught up then it was fine again (not sluggish at all when editing the file).

Are you taking this compiler log from a remote build server? AS in that case it's your network that is the bottleneck as the file is copied to your computer, which could be causing the lock up.

Note: I'm using a 4790k 4ghz with 8gb RAM.

No, the file is not on a network; I don't get why you are in such disbelief... HN complains about a lot of things, but this is pretty cut and dry. I just opened a 2.4MB, 28425 line file containing LLVM IR, and it locks up just scrolling through the file, and the highlighter totally gave up and none of it is colored no matter how many times I try to get it to highlight it. Cutting it down to 5k lines gets me highlighting.

No! You must be lying! I just opened a file and experienced none of that. Therefore it is patently impossible for you to be experiencing what you say you are! /s

Didn't we get enough of this BS in the era where people were "victim-blaming" over BSODs in Windows because "I've never had a BSOD and I've been running Windows for years?"

Did you mean to reply to hacker_9 ?

I feel like it could have been a relevant response to most of the comments in this thread.

I was mocking @hacker_9's continued disbelief of everything that people were saying about Atom's poor performance by replying to a comment about Atom's poor performance.

Like the doctor said, if it hurts when you do that, don't do that.

I use Atom for reading source code because there's a language-specific plugin I like (for Dart). I also use Sublime for looking at output logs when I don't care about IDE-like features, and occasionally emacs or vi from the terminal.

Yea, that's basically what I'm doing now. My larger files are auto-generated source code so all I want is syntax highlighting. I'd like to use Atom for everything because it's pretty slick otherwise, but it's not there yet.