I simply don't understand the appeal of the thing. To a person, everyone who raves about it says, essentially "just like Sublime Text, but in Javascript!", and yeah, that seems right. Just like Sublime Text, but in Javascript...and plagued with the performance problems you'd expect from Sublime Text, written in JavaScript. There's not really a killer feature that makes me want to switch from the editor I use already.

I must be getting old, because "...but in JavaScript!" is not a selling point to me. I don't care what language my editor is written in, except that I'd prefer it to be written in whatever language allows the developers to implement its features in a performant and scalable fashion.

(I really love the downvotes for disagreement. Perhaps, if you like the thing so much, you could explain why, instead of just trying to silence people?)

> Perhaps, if you like the thing so much, you could explain why

I am an avid Atom user who acknowledges how slow the thing can be. None of the slowness on my end approaches any of the horror stores in these threads, but for me, opening the program from a cold boot takes long enough for the wait to irritate me, the first time I save any file after opening the program takes a second or two, and opening a new window takes a second or two.

However, I stick with Atom for a few reasons.

First, Atom is like Sublime Text, but nicer. It has real settings pages! It has a built-in package manager! And although you might consider the fact that it's written in what is essentially a web browser to be a downside, there is a huge upside in that packages can create interfaces with that flexibility that Sublime Text simply can't match - compare something like this https://atom.io/packages/php-debug with Sublime Text's best-effort https://github.com/martomo/SublimeTextXdebug . Not only is trying to assemble an interface out of text buffers not as flexible as a webpage, they also tend to be brittle and break in odd ways if you do any window manipulation on your own - this is actually a complaint I have about Emacs and Vim as well. Also, it just feels like Atom's plugin API is more complete in general - I remember there being a Sublime Text package that required making a copy of your theme so it could add its own styles, and I haven't seen anything similarly hacky in Atom yet.

Second, Atom is open source. I had bought both Textmate and Sublime Text and both of those editors had updates slow to an absolute crawl to the point where it felt like the developer had abandoned them. I feel like Atom being open source makes it less likely to be abandoned completely, especially considering how vibrant the community that has sprung up around the editor.

Having a real settings page and a real package manager are Atom's main draws to me.

I tried to switch back to Sublime after being annoyed with the performance of Atom but kept running into configuration issues and really really disliked having to read documentation on how to configure the damned thing.

I've actually tried a couple of times to make a graphical settings manager package for Sublime, but the second problem of not having an interface beyond text buffers has made it a bit of a non-starter.

> None of the slowness on my end approaches any of the horror stores in these threads, but for me, opening the program from a cold boot takes long enough for the wait to irritate me, the first time I save any file after opening the program takes a second or two, and opening a new window takes a second or two.

How this isn't considered a horror story is beyond me. I'd consider that sort of latency over a the network to be awful, let alone for a local editor.

> How this isn't considered a horror story is beyond me.

Because I generally open Atom once every morning on login, at the same time that there's so much disk thrashing that pretty much everything else is loading slowly too, and leave it open the entire day. Not a huge deal.

Granted, I also don't use Atom for non-programming tasks. If I need to edit a configuration file, or browse a huge XML dump or log file, I use Vim.

I suspect the primary reason people like the fact that it's written in JavaScript is because a lot of people know JavaScript. That makes Atom eminently hackable.

Yeah, OK...but Sublime Text is eminently hackable in Python, and it doesn't get the same sort of rabid adoption from Python devs (it's popular, sure, but not more so than vi or emacs).

It's not just javascript, it's also CSS (well, actually less). I disagreed with where atom put some of its controls, and I just put some CSS in to move them. It was easy.

I understand the question about "why use atom when st3 is perfectly fine?" (or for that matter, vim, emacs, etc). For me, it's primarily the plugin ecosystem. ST3's is good, atom's is better (and feels like it's growing faster but that's anecdotal, not data-based).

Also, in my situation (plugin-wise), atom is super-fast. My source files are usually less than 100kb, usually significantly so, though.

Sublime Text 3:

Build 3103: February 2016

Build 3080/3083: March 2015

Build 3065: August 2014

Build 3059: December 2013

Atom:

1.6: March 2016

1.5: February 2016

1.4: January 2016

1.3: December 2015

User experience-wise, I don't find a large difference between the two editors. Some things are better in ST3, some are better in Atom, but these are very minor things and they're more about my personal preferences rather than the operation of either editor.

The fact that Atom is actively developed however, is a major boon in my eyes. I am confident that whatever bug pops up in Atom will be seen to within a reasonable timeframe. I have no such confidence regarding bugs and issues in ST3.

    > Sublime Text 3:
    >
    > Build 3103: February 2016

I'm just as annoyed as anyone else about the rate of development on Sublime Text, but please, at least state the whole truth.

Build 3109

Release Date: 18 March 2016

https://www.sublimetext.com/3dev

I doubt their intent was to state a half truth. It seems that they were making the point that nearly a year passed between 3083 and 3103.

I also deliberately disregarded the dev builds, since I don't think I'm alone in not wanting to run an unstable/bleeding edge version of a program I work with.

You're argument is no more advanced than the one you're critiquing.

Seeing as quite a few people here are complaining about the performance of Atom, I thought I'd give it a try see if there's anything to it. Cloned the 'Phaser' javascript game engine repo off GitHub and went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance.

I can only imagine that you and the other complainers are running older computers that can't keep up, or you've got a load of other programs running and your PC is having to use virtual memory. I thought it strange that Atom wouldn't focus on performance if it were such a problem as is being made out, but it seems that this is just the case for the vocal minority once again.

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.

Define "a lot of lines". I have used Atom almost every day for the last couple of years now. Startup and opening files of, say, 5mb or larger sucks. But I've never had an issue with opening typical file sizes.

I switched to Atom mostly because of the plugins but I still keep sublime installed for the rare occasions I need to open a large file.

Now I'll admin there have been a few times when I haven't closed Atom for weeks and it'll act a little slow while typing (which can be really frustrating) but closing it and reopening it always fixes it (I'm assuming some memory leak is the culprit).

I just tried opening a 6.3 meg xml file, and Atom was almost unusably slow. Sublime Text opened the file almost immediately and was responsive off the bat.

Tested with a real XML file here:

# wc -l t.xml 315479 t.xml

# wc -c t.xml 10377128 t.xml

Unlike Sublime, it doesn't syntax highlight for some reason, but it does open. Opens quite fast, too. Editing, cursor movement, pagination, etc. all super fast.

OS X 10.11.3, Atom 1.6.0 on a MacBook Pro (Retina mid-2015, 2.8GHz Core i7, 16GB RAM, AMD Radeon R9 M370X).

> Unlike Sublime, it doesn't syntax highlight for some reason, but it does open.

Perhaps Atom is disabling syntax highlighting for sufficiently large files?

Edit: Interesting experiment. Open a small xml file, and syntax highlighting is active. Open a large xml file, and Atom doesn't syntax highlight. Copy and paste the contents of the large xml file without highlighting into the small file with highlighting, and after the text is copied there is a massive slowdown as Atom syntax highlights. I was able to scroll down the file and watch the syntax highlighting slowly propagate through the file.

Interesting -- disabling the xml plugin significantly improves performance for me (but I lose syntax highlighting).

Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.

> Do you mean the built-in "language-xml" package or something else? FWIW, I have it enabled.

Yes, I'm using the built-in language-xml version 0.34.2.

I sure hope it doesn't try to highlight the entire thing, and instead just what is visible on-screen.

With most languages and things like XML it will need to have parsed from the start to the visible area to understand the context (e.g. what if there is comment that started 1000 lines earlier but hasn't yet been closed).

I've been trying to work out what makes VSC so much faster than Atom. Whatever magic Microsoft did really needs to make it back upstream because it'll make using Electron-based apps much less frustrating.

This is a common misconception. Electron is a really tiny slice of these two text editors. Atom and VS Code are text editors and they have completely different code bases for the text editing, so there isn't anything that can be moved upstream.

Monaco, the text editor at the heart of VS Code, is just a lot better (and older and more mature) than Atom's. Perhaps Atom will eventually catch up or simply switch over to Monaco.

Yeah. I thought building a text editor in a web shell was incredibly stupid until I tried VSC. It's still more memory hungry than I'd like, but it's really fast—as fast as Vim for me (but noticeably slower than NeoVim).

Did MS actually modify Electron, did they just write better JS, or some of both?

The reply above yours seems to think it's "just" Electron with better JS, but I'm pretty sure Atom doesn't have DirectX acceleration ;)

It's open source, check by yourself:

https://github.com/Microsoft/vscode/blob/master/build/gulpfi...

which use

https://github.com/joaomoreno/gulp-atom-electron

to fetch electron

> extremely slow and laden with performance issues

I've honestly not experienced this at all; though I'm running Atom/Nuclide with only the Babel language plugin extra.

I think you hit the nail on the head. Slowness in Atom varies so much from person to person probably because it's not in the editor itself, but in the plugins, and everyone has different plugins installed.

Right, that's probably the case. And funnily, the reason why I'm so picky about plugins is that I managed to make both Vim and Sublime Text run horrendously via plugin overload.

Sounds like both should do a better job of telling you which plugins are slowing your system

Atom has something to help with that:

https://github.com/atom/timecop

I've tried running atom several times over its history - first for go and again for elixir. Both times I've had the base version of atom with one or two plugins (go-plus / language-elixir & autocomplete-elixir). I found that, even with that setup, Atom was noticeably slower for all aspects of text editing (opening, navigating, typing, selecting, etc). I also found that the plugins did not work as well as the sublime text equivalents I'd been using (though that's not really Atom's fault).

I really like the idea of atom, but I've found the practical product less than compelling.

I agree with the first point there. I was pretty excited to try an "open source version of sublime text", but the performance was so terrible I ended up just sticking with Vim.

I know people are trying to back away from the console-ui editors, but you cannot deny that,performance wise, it's tough to beat Vim or Emacs.

Agreed. Atom's performance is it's biggest problem. I've been trying it lately and the startup times are very annoying. I find myself reaching for Notepad++ most often just because I don't feel like waiting.