about a month ago there was a lot of hype about atom from the folks at github. the hubbub was great and there was a lot of excitement about what kind of offering github would present to us. once i got my invite, i eagerly installed it and gave it a test run.
user interface
they say that imitation is the sincerest form of flattery and when it comes to the look, feel, and even UX for atom, they took many pages out of sublime text’s book. in fact, i was shocked to see just how similar atom and sublime were. they look and behave so similarly that this is actually atom’s greatest downfall because comparisons will naturally be drawn.
hackability
atom is being billed as a hackable text editor. this slogan is, in fact, prominently displayed on their home page: “a hackable text editor for the 21st century”. at first blush, as a developer, this sounds awesome. i can hack my text editor to do whatever i want it to do? FAN-TAS-TIC. except, when i started to use atom, i realized something: i don’t want to hack my text editor. actually, i don’t want to even think about my text editor. i want to think about my code. yes, it’s great that you can make the text editor do what you want, but is that something that most developers are going to do? probably not.
but what does it really mean to have a hackable text editor? at its core, you expect a text editor to do certain things for you. open files, open multiple files, open multiple files in multiple panes, edit files, save changes, and the like. these are all obvious use cases. it’s in the packages where you tweak the editor’s behavior and extend certain functionalities that developers get that added productivity.
well, it turns out that atom and sublime have the same mechanism, just implemented in a different way. sure, atom’s plugin community is still growing (heck, even the editor is still in semi-private beta), but i’m sure that there will eventually be feature parity with atom and sublime.
atom will go through the same growing pains that sublime text did back in the day. there will be multiple implementations of the same thing with each plugin developer vying to be the one used by the masses. just take a look at the number of jshint plugins that are available for atom now. about three weeks ago, no linter for javascript existed and now they are springing up left and right. finally, someone has written an uber linting framework where you can plug in different language linters, but this sort of stuff is just going to happen until atom matures.
the fundamental difference
so what is the fundamental difference? github’s approach with atom is to bet on web technologies: HTML, JS, and CSS to build an IDE. this means node.js is the language for plugin development and embedding a browser in an app to render the IDE. in theory, this sounds like a really promising and exciting venture. leverage the power of node.js’ npm registry!
to me, this is where there is real promise. the idea that you can write these plugins with node code speaks to me as a front end and node.js developer because it’s something that i’m familiar with and love. that’s cool. but being cool isn’t enough. do i think that i will build plugins for atom? it seems unlikely since other people have already built the things i need, but even if they didn’t, would i really want to pick an editor that will just let me build functionality that i need from it because it doesn’t exist?
to me, that’s where i start to not care. i don’t care if my text editor uses python, node, or BASIC. so long as it has all of the features i want, i’m good.
on top of that, performance for atom is noticeably slower. sure, this is currently in beta, but i wonder how realistic it is to expect performance from a DOM-based editor to compare against a native app. i’m not even complaining about opening big files, i’m talking about scrolling around, there’s just a hint of a delay there that i’m not used to. maybe this can be optimized and it won’t be an issue.
conclusions
at the end of the day, if you can figure out all of performance issues, to me, this comes down to a choice for developers. will plugin developers prefer a node-based architecture over a python one? will a node-based solution provide more capabilities than a python based one?
honestly, i don’t know. atom has a long way to get to feature parity with sublime which is what i feel like its initial goals are. if that is all that they are aspiring to do, then there’s not much innovation there (aside from the underlying technology to get to feature parity). what i really want from my IDE is for it to improve my productivity, to help me make fewer bugs, and to not get in my way. right now, atom isn’t making any of those promises, but no one else is either.
Nice article. I didn’t have a problem with the “imitation”, as you said it’s a form of flattery, and as a Sublime user that just eases the transition for me.
I heard about the performance being not so great but I thought perhaps it’s still usable, I thought to myself, “not so hot” performance in a text editor, how bad can it be? Plus I’m a Node enthusiast, it’s going to be great!
I gave it a go, installed the Minimap package to enhance the Sublime flavour, also installed the Monokai theme, all seemed great to get it going.
When I did get it going, I realised OMG how can anyone use this? SO SLOW
Yes I do work with large files. But the scrolling is crappy even in not so large files. Load the Minimap package and see how even slower it gets.
What’s the point of being able to hack an editor if it gets slow when we add features?
Atom takes time to load up. Takes time to shut off. Takes time to apply syntax coloring when we click the file tabs. The Minimap package is very weak compared to Sublime.
In sum, it just feels like we’re using a broken version of Sublime.
I hope they manage to fix the performance issues.
Until then, back to Sublime 🙂
Alert: GrammarNazi . I’m sorry, the content is fine and I partially share your feelings, but you missed all the (right) capital letters and this drop all your credibility.
For now, I will stick with Sublime. Atom has a lot of potential, but its performance is not comparable to Sublime.
i am agreement with your article.
I’ve tested Atom IDE under Windows, the Alpha version, but actually I was very disappointed, as you say, Atom does not keep its promises compared to Sublime Text.
The developer of sublime Text focused on the speed of the publisher and the lightness rather than gas plants IDE such as Eclipse too heavy.
As PHP developer and sub-framework (Symfony2 or FuelPHP) we did not want to fall within a Java development is well known for its heaviness and their tools.
The time has the speed and therefore developer productivity.
No smooth animation Atom, Very bad support for php and framework, much slower than in sublime text2 autocomplete filtering methods class etc …
But I wonder how you, how could you have as much speed of a program created natively using the Chrome engine, DOM, Javascript?
Just look Brackets Editor for large files, in Bracket must wait long before you can see our css or javascript file is displayed.
In Sublime Text is almost instantaneous, Netbeans and PhpStorm is the same, it’s faster.
I am a little skeptical at the moment, it’s exactly like the editors and IDE to the cloud, quite frankly most developers need to have their IDE on their machine, local and not hosted on yet another tab our browser and especially who will no the same performance as local editor. To be continued …
I use Codelobster for web development