I’ve been using Sublime Text as my primary editor for a little over a year now, and while it’s a fantastic editor, it hasn’t quite been scratching my itches lately. I’ve used a handfull of editors and IDEs for web development over the years: notepad, notepad++, bluefish, kate, gedit, netbeans, and on and on. The whole time, even since my early Linux days as a teenager trying to install Slackware on my 486 (66DX with a sweet turbo button, for the record), there’s been whispers of that editor; The way of the ancient masters, the old greybeards who have spent years meditating in the caves of their server rooms to finally become one with unix: vim.
OK, I’m exaggerating slightly, but only slightly. I (and many others) always assumed that using vim was hard. Over the years I’d flirted with it here and there, firing it up only to get frustrated that I couldn’t even edit a config file before giving up and switching to nano (after spending five minutes figuring out how to quit).
Yet as time passed, more and more of my peers used vim simply as a matter of course. I gradually became embarrased to nano in front of my colleagues. Considering my recent discontent with my current editor, and a preponderance of my fellow developers using vim, I decided I’d finally bite the bullet and learn to use the thing.
One of the most often recommended ways to get started with vim is with its built-in help tool, vimtutor. As you approach the end of vimtutor, you’ll encounter lesson 7.2, which begins with:
Vim has many more features than Vi, but most of them are disabled by default. To start using more features you have to create a “vimrc” file.
Oh. OH. Why the hell isn’t this the first thing they tell you about vim? What this is basically saying is that, by default, vim is vi, straight from 1976, and it’s up to you to gussy it up however you want. Now I understand why I never liked vim before, I was using it like vi, and vi is terrible.
Here’s vanilla vim (no modifications on RHEL):
Yeah, you’ve probably seen that before. You’ve tried to make a git commit or edit a text file at the command line and faced that horror. Who would want to suffer through that archaic mess?
Almost looks the same, right? Here’s the thing: Experienced vim users will tell you not to start with the training wheels. You’ll be told to start with just plain vim in the terminal, learn to use hjkl to navigate, don’t worry about a vimrc, and so on. Don’t listen to them.
As a web developer, all you really need is a text editor. Vim is a text editor alright, but it’s a text editor born in an age where mice hadn’t been invented yet, where window managers didn’t exist, where the internet wasn’t a thing, and where a fair number of current web devs hadn’t even been born yet. So why do web development with it? Especially in the year two thousand and fourteen?
The fact of the matter is, you have work to do, and if you can’t fire up a new tool and get to work, you won’t use it. Go ahead and use the training wheels. Steal someone else’s .vimrc file, steal the good parts from internet guides, use gvim (or macvim or whatever if you’re not cool enough to use Linux), use the arrow keys (don’t worry about that hjkl thing), use the mouse. Once you have those, if you can learn the difference between command mode and insert mode, you’re off to the races and should be working just as well as you could with something like Kate or Notepad.
Now, here’s where the magic happens: Because vim is from an age where window managers didn’t exist, it’s perfectly at home in the terminal. If you, a web developer, are anything like me, a web developer, you probably have to work on a remote host every now and then. That means you probably have to use ssh every now and then, and that’s probably why you’ve had to experiment with vi or nano in the first place. On a remote, you can’t bring Sublime with you, but vim’s happy to come along for the ride and it’s probably installed on your dev server already. All you have to do is copy your .vim directory and .vimrc file to the remote, and you’ve got your full editing environment anywhere you go (consider putting your .vim and .vimrc in source control on, say, GitHub for portability).
That’s really all it comes down to: While the introduction probably needs to be updated for the 21st century, vim is a perfectly capable text editor like many others, but its strength, for me at least, is in its portability. If you’ve ever considered using vim, go ahead and give it a whirl, but, for now, go ahead and ignore the ancient masters. Vim’s a great editor, but maybe it’s time to rethink how we’re using it these days.