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.