On April 14th, 2016, Microsoft announced the 1.0 release of their open-source Visual Studio Code (VSCode) editor. I’ve been drive-testing it for a few months and have been quite pleased with it, so here go my impressions.

How did I get here?

Let’s backtrack a bit first. I’ve been a Vim and Emacs user for many years. Yes, I use both regularly depending on what I have to achieve. For me, Vim shines in doing quick single-file changes and repetitive edits through many files, while Emacs shines in long-lived coding sessions that involve numerous open buffers. These editors are well-suited to my remote-based coding workflow because they run just fine in the terminal. However, sometimes I just would like to take advantage of the desktop environment and the GUI of these two editors on OS X… err.. sucks… so I’ve been wanting to find something else.

As a result, with all the hype around GitHub’s Atom last year, I decided to jump on the bandwagon and gave it a try. My first encounters with Atom were not great: I found the environment bloated—just look at the endless settings and extensions panel—and clunky: the UI seemed convoluted, and Atom would routinely spit internal errors when performing “usual” editing tasks. Granted, these were probably caused by the extensions I had installed… but I don’t think I installed anything out of the ordinary!

No matter what, I carried on and used Atom to write the first version of this site. The experience didn’t “hook me” so I couldn’t be bothered to use Atom for anything else. But, soon after, VSCode entered the scene with a similar premise to Atom, and in fact built on the same platform. You may or may not like Microsoft, but they are pretty damn good at building IDEs… ergo VSCode deserved a try.

Enter VSCode

VSCode’s interface is pretty barebones. There is nothing particularly shiny about the editor when you open it the first time: a sidebar with four spartan sections and an empty content panel to display files. If you dare to launch the settings editor, you are met with two editing panels: one on the left to display the default settings in JSON format, and one on the right with an empty file waiting for your overrides. Uh huh?

That’s right. At first sight, VSCode can give the impression of being a joke—I certainly thought so when I encountered the, literally, settings editor—, but that’s very far from the truth.

Start using the command palette to navigate files and commands; it’s like Emacs’ M-x, but magical. Notice how non-intrusive but powerful the Git integration is—and I heard that it may be even better than Atom’s, which would be ironic… Navigate the editor with reasonable keyboard bindings, just as you would expect. Appreciate the utter simplicity of the configuration mechanism. And, the icing, install extensions: as I understand it, VSCode’s initial target was to support web-based languages, but production-quality extensions now exist for native languages—including C#, C++, and Go.

I’ve personally come to enjoy using VSCode. Part of this is because the editor made me so much more productive writing code in a new language, Go. As I hinted in a previous post, having semantic auto-completion, assisted code navigation, and automated code reformatting plus validation are invaluable features when navigating a new, unknown language. I’d have certainly written Go code in Emacs (and that’s exactly how I started), but it’d have been a much more painful experience.

There are also teeny tiny touches that help everyday tasks. One example is the preview of colors when entering color codes in CSS: the editor displays a little box next to the code filled with the color you provided. Another example is how hovering on CSS properties or JSON configuration properties pops up a bubble with more information about the symbol underneath and all possible values.

Open source project

Can Microsoft deliver an open source project without strange licenses and with development happening in the open? It indeed seems so, which is an 180-degree turn from what the company did a few years ago.

VSCode is an open source project in all regards: the code is released under the very liberal MIT license (but see these FAQs), the project is hosted on GitHub, and Microsoft has been able to create a community around the editor. Make no mistake: VSCode is not a code dump. (I’ve personally filed a few feature requests with them and, even though my requests were rejected, the rationales they provided were convincing and the timeliness of the responses was much appreciated.)

Workspaces

Back to the settings chatter, one particular detail I have come to like is the ability to trivially define and customize workspaces (aka projects): create a .vscode/settings.json file at the top of your tree with any project-specific configuration overrides (e.g. indentation tweaks) and VSCode will apply those transparently. I appreciate the fact that this has to be done explicitly and that the contents of the file are super-simple and human readable. Contrast this to, say, Android Studio, which creates an .idea directory with almost-unreadable contents.

With the right command-line alias, all you have to do is type code . at the top-level directory of your project to launch a new instance of VSCode ready to work on your project—and the editor remembers where you left off last time. In case you are curious, an alias for OS X would be:

alias code="open -a 'Visual Studio Code'"

Some bad parts

So what about the bad? I don’t have much to complain about, really.

Obviously, the fact that VSCode is a graphical editor means that it is not usable on the terminal, which is a blocker for doing remote work. Similarly, VSCode currently only supports Windows, OS X, and Linux; I don’t think there is any technical blocking the support of other systems, but the port needs to be done and is probably not super-easy.

Lastly, while the authors praise VSCode’s small size, I don’t really buy it: the fact that the editor is based on Electron, weights several megabytes, and takes a few seconds to start counters this. But, really, none of these have bothered me.

Parting words

If for any reason you would like to try a different editor, I’d certainly encourage you to give VSCode a chance. Make sure to go over the editor basics document to familiarize yourself with the environment and delve into the more advanced topics later on.

I, for one, will continue to use Vim and Emacs for a lot of my work, but VSCode has gained a spot for certain types of projects. How this split will balance in one direction or the other, only time will tell: there are things I like and dislike in both camps. But remember: it’s all about choosing the right tool for the job, so restricting yourself to just one editor is most likely counterproductive.

If you let me… I’ll conclude by saying that Atom is to Emacs what VSCode is to Vim. “What do you mean by this?” you say? Ah, I don’t know, you’ll have to figure it out yourself!