Thoughts on Atom vs Zed
So, Atom happened, github's web tech-based code editor. I have an Atom invite and I played around with it a bit today and it's an interesting project -- and with the weight of Github behind it, definitely not something to ignore.
Of course, as the author of Zed I have to ask: how does Atom compare to Zed, and is there any reason for Zed to exist anymore? In this post I'll try to compare and contrast the two a little bit based on what I've learned so far. Of course, all of this is somewhat biased, but I try to abstain from criticism at the level of "WHY COFFEESCRIPT!? COFFEESCRIPT SUCKS!!1"
Atom is, due to its strong ties to node.js APIs, less portable than Zed. Zed currently runs as a Chrome app, and in prototype-form as a node-webkit "native" app. But it's easy to also make it work as a regular web app, if need be, or as a Firefox App if that ever becomes a thing. That said, of course, getting access to node.js directly allows the editor to do anything node.js can do (= basically anything) and Chrome or web apps can't.
Zed has the explicit goal of doing things differently regarding the concept of open files and tabs (or lack thereof), minimalism in UI, unifying file opening and creation, and remote file editing. Atom basically looks like sublime: file tree on the left, tab bar along the top, and borrows features like goto and the command panel from Sublime and Textmate too (Zed does too, but has tweaked the way goto works). Atom is more "traditional" UX-wise, which is a perfectly legitimate choice.
I'm not going to do a feature-by-feature comparison. Let's say that Zed and Atom are relatively close in terms of feature set. Atom is probably stronger in terms of find and replace support (regex support, find and replace in project). Zed is stronger in language support (extensible code completion, inline markers for linters, symbol indexing, code formatters etc.) and remote file editing. The reason for Zed's language support focus is obvious, considering where I came from and you can expect more features in this area in the future.
Since both are extensible editors, my response to any missing feature in Zed can be "well, just fork the project and add it, or create an extension" and Github will say "well, just write an extension."
From the beginning the ability to extend Zed (beyond forking the code) has been high priority for Zed, however being a Chrome app limits its flexibility a bit. If you want to use Chrome APIs like getting access to the local file system, you need to run in a "safe" mode that does not allow a lot of things like eval'ing arbitrary (user) code. Therefore, in Zed, all extension code lives in a sandbox in a separate process. Zed exposes APIs to the sandbox to do certain things like using basic UI elements, getting access to files etc. Zed extension points are designed in advance and not accidental. Zed provides specific extension points to extend its built-in code completion, symbol indexing, linting etc. support. There are (currently) no APIs to make arbitrary changes to the DOM, listen to arbitrary events etc. Zed may eventually get these features, but they have to added explicitly.
However, putting extension code in a sandbox has two advantages:
Extensions can interfere with the main process in limited ways, it's difficult to make the main editor crash as a result of poor extension code, and because the sandbox lives in a separate process, performing CPU intensive tasks also does not slow down the editor.
It is easy to reload extension code without having to reload the whole editor (by simply killing the sandbox and restarting it). As a result, extensions can be developed without having to relaunch Zed, but just by resetting the sandbox.
Licensing and cost
How Atom will be distributed once it leaves beta is not 100% clear. Most likely it will be free, but not open source with some sort payment model attached. Github is trying to find a balance between the ability to earn money on the product, while still open sourcing as much as possible. Zed is 100% open source, MIT licensed.