Goodbye Atom, some feedback


I want you guys know that transparency is important to me. Surfacing more information will take some time but it will be worth it. It’s something I’d like to focus some attention on once the API freeze is completed in a few weeks.


For some reason sublime 2 on my system took 5 seconds to load. I never understood why. Maybe a bad plugin.


Sublime 2 loaded plugins as part of the main sublime executable. Sublime Text 3 loads plugins as part of the plugin_host(.exe) binary, which gets launched as the editor itself is starting. So while Sublime itself opens up immediately, the plugins will take a couple seconds to load (and is why package control doesn’t rant at you immediately)


It always excelled at performance and that is where atom lacks. In my case ST3, lightning fast, 94* plugins, 0.204ms startup time on a project with thousands of files.

The language is the last of worries unless it’s hindering performance or a real technical challenge that is preventing from progressing forward.

zekesonxx beat me to explaining this.


FYI: The pull request information is in the email headers. Gmail has even added a feature recently that has a link to github on the right of the subject line and it even says “pull request”. But they hard-wired this feature and it is impossible for a user to filter pull requests separately from normal github issue emails.

I also searched for 3rd-party extensions to do this with no luck.

It would be easy to do this in node. The is a great node-imap module I could use to find pull requests. It could dump pull requests into an Atom page. The subject lines could link to the actual issue on Github. It could also use other custom filter criterion. I somehow doubt there would be interest in reading email in atom since there a zillion email clients.

It’s only advantage would be advanced header filtering. Would there be any interest in a package like this?


Totally agree about the CoffeeScript. It needlessly fragments the community. It’s especially a problem in areas discussed here

Why coffeescript?

I’m in the same position, I’ve switched from Sublime Text to Atom since January, but now I’m switching back to Sublime Text.

A few things that I expected and didn’t quite make it, yet.

Speed - atom is quite slow, and I’m not comparing it with Sublime, I’m comparing it to other online IDEs which are build using the same tech.

CoffeeScript - oh my - a stubborn decision to still continue down this path. I won’t be amazed to see a complete rewrite in the future, like “Atom 2 - now in JavaScript!”

Very buggy, the amount of open issues is daunting, I had some serious issues with vim-mode and the editor’s buffer, was typing something pressed Shift+v, selected text, pressed another command and the console popped with an error, and what I selected was deleted and no way to use undo as everything I pressed gave another error. Went to report the issue and saw related issues open since a few months ago.

I really appreciate your efforts, I really do, but Atom needs a very stable and fast core.

The modularity it introduces through packages is extraordinary, but in my opinion was released too early. Developers jumped in and started to write packages, which was great, until you install a few of them and it feels like an IDE running in IE8.


Why on earth is this a “stubborn decision”, and why would they “rewrite in the future”? What possible benefit would that have?

If you feel the open issues weren’t addressed, then you should take a stab at fixing them. That’s one of the primary benefits, and purposes, of Open Source Software.

You do realize how ridiculous that statement is? Complaining about an open source project being released too soon? :wink:


With regard to the CoffeeScript part of this discussion, this has been hashed to death over on this other topic:

Any future replies regarding CoffeeScript versus JavaScript should be directed there … if anywhere.

I find it curious that people who claim to be walking away from Sublime Text because it chose Python for its scripting language and Atom because it chose CoffeeScript can’t imagine that some people (probably myself included) would choose to walk away from Atom if it had selected JavaScript. No matter what decision is made for the scripting language, it will alienate some group of developers. That’s just the nature of things … we all have our preferences. So let’s stop chest thumping about it.

Finally, let’s keep the discussion positive and the language civil. Constructive criticism is the goal here, right?


Out of a sense of morbid curiosity, yes! :smiley:
I’m sure it’d be an interesting challenge, if nothing else.


Probably would be for a mere mortal. I’ll put it on my list. Having you as one user would be a bigger user base than some of my packages.


It hasn’t been released yet. It’s not 1.x.x.


I was not looking for a religious discussion over CoffeeScript, it is my opinion.

When CodeMirror 2 was published, I took the source and started to make it modular like Ace was. But the author wanted to keep everything in one file (around 4k lines of code). I opened and issue and wanted to follow with a pull request, he disagreed and I gave up.

Same happened here, I got excited early on when I received an invite, was super excited when it was released as open source and then … felt a little disappointed.

Maybe because Atom is sponsored by GitHub, I expect a certain outcome for this project; if you feel that expect is too demanding, I’m sorry, but that’s how I feel.

Somehow related - Douglas Crockford at a Yahoo conference had a harsh commend about Node.js’s source code and how it’s handled. At time I felt like saying “F$#@ off dude!”, a year later, seeing how Node’s major release was delayed over 6 months, you start to understand his arguments.

Maybe Atom failed to attract contributions from experienced JavaScript developers, and we all pressure the core team.


Warning: This topic is rapidly devolving into ad hominem attacks and general adversarial language. Those who are resorting to name calling (examples: “ye of little patience” and “failed to attract contributions from experienced JavaScript developers” among others) are encouraged to review and edit their posts to clean up the content.

Warning: Any more posts regarding the CoffeeScript vs. JavaScript debate will be either moved to the topic I pointed to earlier or hidden and the author will be asked to rewrite the post.


Sublime Text first public release: 18 January 2008 (From wikipedia)
Brackets first public release: 24 July 2012 (first release post on the official blog)
Atom public release: 26 February 2014 (first post on

Given that ST hype is 2/3 years old max (with ST2 I guess) I think Atom has some room to mature. And that’s what I like about it! They released it early enough so that people interested in the project can make significant contributions and suggestions early. That IS the purpose of open sourcing a project. Obviously it can’t compare yet with already stabilized products that made different design choices. I really liked ST, I must say I’m always opening it from time to time when I hit Atom’s limit, but, hey! Atom has less than 8 months of public access, and, yes, it has bugs. But WE can fix them!


I could be mistaken, but I don’t interpret that latter quote as an ad hominem attack. I interpret it to mean “failed to attract contributions from skilled developers that work with JavaScript but not CoffeeScript”. In other words, I don’t interpret it as disparaging the developers that do work on Atom or work with CoffeeScript in general, I interpret it to mean that there are many more developers skilled in JavaScript than CoffeeScript, I think the implication being that perhaps development of the core and resolution of issues is slower than it would be otherwise because the pool of people who can contribute is smaller.


I moved a post to an existing topic: Why coffeescript?


Ad hominem arguments are arguments that are directed towards a person (or in this case a category of people, i.e. the people who have chosen to contribute to Atom) rather than an idea, i.e. the relative merit of CoffeeScript versus JavaScript as a language or the use of them for a project.

Your interpretation that there is a bigger pool of JavaScript developers than CoffeeScript developers and how this might affect the speed of development of Atom would not be considered an ad hominem argument because it is directed toward the speed of development, not the quality of developers. And perhaps that is what the author intended by their remark, but it wasn’t phrased that way in my reading of it.


That’s all my interpretation of what @navaru wrote, although I certainly believe there are many more JavaScript developers than CoffeeScript developers (I assume no one disputes that). I personally have no idea if the decision to use CoffeeScript as opposed to JavaScript has actually affected the number of contributors or pace of the project.

Yes, I understood what you meant. I can’t speak for @navaru, but yeah, that’s my point: when I read that line I don’t think they are referring to the people who have chosen to contribute to Atom. I think they’re referring to “experienced JavaScript developers” who have not contributed, people who might have if it was written in JavaScript but haven’t because they don’t work with CoffeeScript.


I moved 2 posts to an existing topic: Why coffeescript?

Why coffeescript?