Choosing a Text Editor: An Important Decision Demystified

Photo by Fabian Grohs on Unsplash

This article is part of a series introducing new developers to building web applications in JavaScript without frameworks or any other “magic”. You can see all the articles in the series here.

In every developer’s journey, there comes a critical moment when she makes the most important decision a developer can make: what text editor to use

Disclaimer: this is not the most important decision a web developer can make. In actuality, this is probably one of the least important decisions a web developer can make. If you are a web developer and have happened upon this article, your best option is probably to not read this article, choose whichever editor arbitrarily looks best to you, and then spend the time you saved really learning how to use that editor to maximum effectiveness.

At the moment, I personally use Visual Studio Code. In the past I’ve used Sublime Text, Atom, and even vim. I’d say if you are a beginner, and just need me to make the decision of which text editor to use for you, go with Visual Studio Code. Now with that out of the way you can happily carry on with actually coding (which is the important part). If you’re still interested in reading about what shapes my opinion about what qualities make a good text editor, then by all means continue on.

Instead of listing the arbitrary differences between The Top Ten Text Editors, in this article I’m going to lay out the aspects of a text editor that are most important to me. Basically it comes down to three high-level qualities: Ergonomics, Extensibility, and Speed

Ergonomics

Typically when we talk about ergonomics, we’re talking about things like the shape of things in the real world, and whether or not they lend themselves to easy use. An ergonomic keyboard, for example, is one that allows for long periods of use without causing fatigue or damage to your hands. An ergonomic cell phone would be one you could easily use with one hand, and that didn’t cause severe damage to the outer ear during every use. If you find an ergonomic cell phone, please send me a link to it. We can talk about ergonomics as it relates to text editor by considering how easy it is for you, as a developer, to write code with that text editor. An ergonomic editor is one that reduces the friction involved in writing code. If at any point you find yourself slowed down by your editor while writing code, you’re suffering from some kind of non-ergonomic situation. Of course, this also relates to the first and most important point in this article: learn your editor. An editor is only ever as as good as the developer using it.

Learning curve

It’s important to keep in mind your skill level and experience as a developer when consider the ergonomics of a text editor. A skilled developer with lots of previous experience using vim might find an editor like neovim to be incredibly ergonomic right off the bat, because they’ve already invested the time learning how to effectively use vim-like keyboard commands. An example on the other end of the spectrum would be a complete programming beginner. For them, both vim and neovim would probably be incredibly non-ergonomic, because of the alien nature of vim commands relative to ‘normal’ computer keyboard commands (the easiest example being the use of ‘hjkl’ for simple navigation through a document versus the use of arrow keys in a more normal text editing environment). In this case, vim and neovim could be considered as having a steep learning curve, but with a beneficial increase in productivity once some time has been spent on that curve.

A text editor like Sublime Text or Visual Studio Code (VS Code) will have much improved beginner ergonomics over something like vim. This is because the editors aim at least in part to be a familiar text editing environment, with commands like ‘ctrl + c’, ‘ctrl + v’ and arrow key navigation carrying over from more general text editors like Word or Google Docs. However, neither Sublime Text nor VS Code should be considered slouches compared to vim; Once you spend time learning the features of these editors, their power becomes apparent. This idea of ‘easy to learn, lots to master’ is applicable in many domains, including for text editors and is something to consider as a serious plus when choosing a text editor.

Extensibility

Extensibility is what I consider to be the next most important quality of a text editor. Extensibility encompasses any aspect of a text editing tool that allows for an increase in functionality outside what the editor offers by default. Editors like VS Code, Sublime Text, and Atom are great in this regard. Usually, the way you extend a text editor as a web developer is by adding extensions specific to the language or tools that you use. By default, most editors don’t come with a ton of language highlighting, for example. A React developer is greatly benefited by React-specific highlighting, and if an extension isn’t available for that use-case then that editor is not a good choice.
Most popular editor offerings these days have a wide selection of extensions for most use-cases, but if you happen to be developing in a less popular language or are using less well-known tools, then choosing an editor that can accommodate your workflow is a must.

Know your domain

An example of an editor that has decent ergonomics but no extensibility would be the Notepad app that comes standard on Windows machines. It has a familiar interface, keyboard shortcuts, and is fast at editing text. However, there’s no way to extend it for use as a code editor. Another example is the nano text editor, which commonly comes along as part of a Linux distribution. A Rustlang developer who is using Nano would have a limited number of offerings in terms of text highlighting and build tool integration, whereas an editor like VS Code offers many different extensions for the Rust language specifically.
It’s important to always take your use case into consideration when choosing any tool, especially a text editor. Before you settle on a solution, it pays to check whether there’s a robust selection of solutions for problems you may run into in the future while using that tool.

Speed

Speed is arguably the least important of the three topics I’ve listed here, but it’s still important none the less. It’s also the most self-explanatory. You want an editor that edits quickly. This seems like a no-brainer, but one of the reasons I stopped using GitHub’s Atom editor was that even though it was both relatively ergonomic and incredibly extensible, those positives came a cost: Atom was slow. After installing things like linter’s, code formatters, terminal extensions, and whatever other extensions to Atom’s functionality I needed, there was an apparent latency when actually editing text. On top of that, Atom took forever (or so it seemed) to start up if it wasn’t already running. A lot of this no doubt has to do with the fact that Atom is built using Electron, which already puts it at a disadvantage compared to natively implemented solutions. VS Code, which as you know is my editor of choice, is also built on top of Electron. However, the difference between the two is apparent right from the start. At the time of this writing, VS Code version 1.29 for Mac weighs in at 192.1MB. Comparatively, Atom 1.33.0 for Mac is a whopping 854.6MB. Even on relatively fast modern hardware, that's a significant size, especially when you consider the main goal of these applications is to edit text. If you look at offerings like SublimeText (33.6MB) or neovim (3.8MB!!!), even VS Code seems comparatively overweight. Of course, it's important to keep in mind that application size isn't the only determining factor in runtime speed, but it is definitely a consideration.

Speed is the one aspect of text editors in this article that is largely dependent on what your hardware looks like. If you are using a modern high-end laptop, chances are that any editor is going to run fast in most situations. However, if you’re on older hardware or a more limited device, using an offering like Atom become basically untenable. I use VS Code on most of my machines, but when I need to do some work on a device like a Raspberry Pi, for instance, Even VS Code isn’t an option and I’ll end up using a smaller editor like Sublime Text, vim, or even C9. Like many other things in programming, keeping outside factors in mind is an important part of the decision making process.

Other notable offerings

Obviously I haven’t gone in depth about all available text editors in this article. Here are some other interesting considerations for what tool you should use:

• C9 An IDE wholly based on the cloud.
• Brackets An interactive, JavaScript based (one of the first to do this) editor.
• LightTable An offering with a different perspective on what you should expect from a code editor.
• Nano Always there for you when you need it.
• Emacs I have to at least put it in here, right?
• Dreamweaver CC I’m kidding, obviously.

Wrapping up

In this article we’ve explored my take on what makes a good text editor for web development. A quick recap (let’s make this stick, shall we?): Ergonomic text editors reduce the amount of friction between the developer and the code she is writing. Speed is just that, how fast your editor edits. Extensibility encompasses any and all the ways you can make your editor do specific things outside of just editing text.

Now, go write some code.

If you’ve made it through this article, hopefully I’ve provided a bit of new insight into the very overdone topic of choosing a text editor for web development. If so, please consider sharing this article with others, or giving it a few claps.

Thanks for reading.

Originally published at tndl.io on December 9, 2018.