A while ago GitHub announced that they are currently busy developing their own editor. This announcement created a lot of buzz and got quite some attention. Shortly after the initial announcements it was obvious that the editor would be build upon web technologies - namely HTML, CSS and JavaScript. The core of the editor will be fully powered by node.js, with the GUI being rendered by the embedded Chromium browser.
This does not sound new, does it? Almost two years ago I proposed such applications, however, I did not see it coming that such an architecture would be used for an editor. And this is not the first attempt. Already the LightTable application represents an editor that is using web technologies for rendering its GUI. While the two applications seem to have a lot in common, they also have a lot differences.
Let's start by praising the advantages of this architecture first: As it is using a dynamic language the application is really flexible, quite easy to extend and open. And in fact, both - Atom and LightTable - are build around extensions. In fact, while Atom seems to have copied a lot from Sublime Text 2, LightTable tries to come up with a really unobtrusive user experience.
Now this is also where both start to diverge. LightTable is currently only targeting web technologies - it is in fact hugely inspired by Bret Victor's talk about new IDE experiences. This IDE lives from live views, interaction between running code and editing code and its minimalistic core. On the other side, Atom tries to look like a classic editor, however, much nicer - with integrated debugging and fully extensible. Atom also supports a lot more languages out of the box. In fact, Atom already detects directories, contains a markdown preview and a package manager out of the box.
This all sounds great. Why shouldn't I pick a free editor that runs on every platform and might even be ported to the web without difficulties? Currently the issue is performance. And it is in fact a huge issue. Atom is taking really long for trivialities like searching some fragment. In fact a simple search should always be O(n), but obviously it is taking much longer. The problem seems to be that not the text is viewed, but the DOM tree. Therefore we need to walk in a tree of DOM nodes, which are not consecutively aligned in memory. There will be a lot of jumps and overhead. A simple search in a 1 MB text document took several seconds. This is far too long.
At the moment Atom is only available for MacOS. But this is just a distributable, and the project is open-source. Building Atom for Linux or Windows is easily possible. For Windows that just implies installing the latest 32-bit node.js, and the last 32-bit 2.7 version of Python. It is recommended to use a PowerShell instance that has been configured by the GitHub client. Finally one can built Atom, which might take several minutes due to package download or other tasks by either npm or grunt.