Wednesday 21 September 2016

The Editor Wars - 21st Century Edition

For many years, there has been a split in the people who use Unix text editors and, with the turn of the decade, this has been extended to new ones, which seem to be taking over the developer world.

In case you don't know, I am talking about vi (these days, Vim) and Emacs.

Due to historical reasons, the Unix editors are not friendly to new users; they were created for text consoles, their shortcuts are completely non-standard and many concepts that we take for granted, such as windows or tabs, are hidden or unavailable in their user interface. As a consequence, they have a steep learning curve and require time investment just to get fluent with them and that knowledge does not normally transfer across to other programs.

The reason why these editors not only still exist, but are still actively supported and widely used, is that they are extremely flexible. Emacs, in particular, allows you to overwrite any behaviour via its embedded language, Lisp. Vim, while more limited, trades these limitations for a faster interface and lower footprint. For a long time, there was nothing as powerful as any of them.

Then Atom happened.

Atom comes from GitHub and it's designed from the ground-up to be an extensible editor. As opposed to Emacs, it embeds a really common language, JavaScript, and you can change its looks via CSS and HTML. In a very short time, it has gained capabilities that rival (or surpass, depends on who you ask) those of Emacs, while providing a modern interface and using standard conventions and key mappings. It is also multi-platform, supporting Windows, Linux and Mac OS.

Another problem that Emacs and Vim have is that they are designed as console text editors, everything is a text area. While that is extremely powerful, it also makes it really hard to to some things that we now take for granted, such as having drop-downs that stand out or different behaviours in panels.

On the other hand, the problem with Atom is that everything is, under the hood, a webpage. Atom embeds Electron, which is an embedded version of the Chromium engine, the same that powers Safari, Google Chrome and others. This makes it extensible and good-looking, but also slow, memory and power hungry, especially compared to Emacs and Vim (old-timers will long for the time when Emacs was considered a huge, bloated piece of software).

Despite of these issues, the usage of Atom has grown exponentially, the performance has improved and you can now find just about every plugin you want for it.

Not too long ago, Microsoft released an alternative to Atom, Visual Studio Code (VSCode for short). As Atom, VSCode is based on Electron but performs better because the VSCode API restricts what plugins can do.

After a couple of versions, Atom became fast enough for me and I started using it for all of my development, but something didn't feel right. I tried VSCode a few times but it just didn't feel right. I kept on trying and, when working with F# on the 1.4 version, VSCode finally clicked for me and I have now switched over.

This situation matches my experience with the classic Unix editors. My choice was Vim because it did feel right - it wasn't as powerful but it was good enough and didn't get in my way. Every time I used Emacs, I ended up frustrated, I just couldn't get it to feel right for me. I even used an Emacs clone for a while in preference to the real thing, Jasspa Microemacs, as that worked better for me.

So, the parallelism here is that VSCode is the new Vim, while Atom is the new Emacs. The differences are much smaller than before, you can't call VSCode a lightweight editor and the functionality is a lot closer, but the approach is similar.

As always, it's a trade-off.

Which one do you prefer and why? Feel free to leave a comment.

PS. I have not mentioned Sublime - it would be my ideal choice if it was open source but it is not and the number of plugins it supports is a fraction of what Atom and VSCode have.

No comments:

Post a Comment