Atom is a text editor made by Github. It’s in a large, “invite only” beta. It’s got bugs, it’s slow, and it’s sometimes uncomfortable to use. It’s also currently Mac-only.
You should start using it as soon as possible. Let me explain why.
Atom was designed to be extensible and modular from its inception. The core of Atom is neither open source nor available — but I was pleasantly surprised to discover that much of the functionality is defined in open-source packages outside of core. Here are a few of the 150 packages in Atom’s public repositories.
- The fuzzy finder
- FuzzAldrin, the scoring algorithm for the fuzzy-finder
- The tree view
- The model class
- The view class
- The events framework
- Even text-buffer, which handles ranges, selections, an edit history.
It is apparent from its architecture that Atom wasn’t just built to be extensible — it was built by extending.
Why Bother with an Extensible Editor?
A non-extensible editor forces you to rely heavily on the design foresight of its creators. You will only ever have the functionality that they expected you to need.
Many people limit their editor customization to adding a nice theme, a few additional keybindings, and a plugin or two. I spend all day in my editor; it should mold itself to me and my needs, not the other way around. And that means more than just soothing colors.
Anything I do frequently I should automate. It’s even better if someone else has already automated it for me. An editor that can’t (or won’t) let me automate tasks is a faulty tool.
What about Emacs?
“Why not use Emacs?” you say; “Use something that’s stable, tried, and true!”
I love lisp; I think it’s the bee’s knees. The first programs of any real complexity I ever wrote, I wrote in lisp. Lisp is crisp, clean, and excitingly modular; it is refreshing like a spring rain.
Emacs lisp is a rain of sewage. It’s dynamically scoped. There is no namespacing. ‘Tools’ like
defadvice make it impossible to be certain of any function’s behavior. Regexes, stored in strings, are hideous and unreadable.
I can and have written useful programs in Emacs lisp; Emacs has been my editor of choice for more than 5 years. Writing little utility functions is fast and usually easy, but writing good packages requires grunting and sweating under weary code.
Emacs is the most extensible (and the most extended) editor ever made.
Emacs lisp is the language of Satan: powerful and evil.
Yeah, well, what about Sublime?
An editor extensible in python? Sounds delightful!
Surprize! Developing for sublime sucks, too. To get a single command — one that you must run manually from sublime’s terminal — requires creating a whole plugin; and doing so ain’t easy: the API documentation is one page long.
Sublime Text’s package manager has a little more that 2,100 packages on offer.
Emacs’ combined repositories have ~2600 packages in them. (OK, OK, there are thousands more not in any package manager, but are undiscoverable packages really a selling point?)
Atom already has (as of my writing this sentence) 850 packages available.
Atom’s been around for less than 2 months, it’s invite-only, and only mac-based developers can use it (so far). 850 packages.
Some of these packages use Theorist as a model class; some use Backbone; some embed code directly in Space-Pen views. My conclusion: more people are writing for Atom, they’re writing faster, and they’re writing using more diverse tools. Writing packages for Atom calls on front-end web development skills that are already wide-spread, and the core editor was designed to be extensible from the get-go.
But the Atom team knows the API’s weaknesses, and is dedicated to solving them. Atom has bumped up several patches and one minor version since I wrote the first outline of this post last week.
Atom is NOT a better editor than Sublime or Emacs. Certainly not right now. But in 5 years, what will it be? It’s my belief that you’ll decide to switch to Atom (or something like it) in a few years, because some new and clever extension will appear that you won’t be able to ignore. Start using Atom today: contribute to the editor you’ll be using tomorrow.