LazyVim for Ambitious Developers

This book is meant for all the developers out there who are intrigued by the power they have heard modal editing can bring, but are either intimidated or bored by the sheer amount of configuration that even introductory tutorials on the topic force upon them.

I’m guessing you’re a Visual Studio Code user (a great editor that I used for a few years) but you may be coming to modal editing from numerous other integrated development environments and code editors. You’ve probably heard of Vim, and likely been caught in the “how do I exit” loop once or twice in your life, and now you want to try it out.

Why Vim

Vim has a very ancient history. It was created in the early ’90s as an improvement on the (much) older vi editor, written in the 1970’s. The name vim actually stands for vi, improved. Vi itself is short for “Visual”, as it was an iteration on a even earlier (1971) non-visual line editing experience called ed.

Interestingly, ed is somehow still available on modern Unix systems, and if you use a MacOS or Linux environment, you can probably access it by typing ed in any terminal. (If you made the mistake of trying it, Control-D will get you out again). You now know as much as I do about ed, and trust me, you don’t want to know more.

You may also be familiar with another iteration of ed called sed, the stream editor. To this day it is still used for modifying text in a shell pipeline.

The ed command was also extended to create another line editor called ex, which isn’t really used anymore, except (extensively) as a submode of Vim. In fact, if you install Neovim and type ex on your command line, you will get a very crippled instance of Neovim that only supports ex commands.

So that’s quite the family tree, but ancestry alone is not a great predictor of quality, as any fourth generation somebody can attest.

There are many reasons to use any one given editor, but (from my point of view), the three that stand out for Vim are:

• Health Benefits: This is the big one for me. I used Vim a lot through my early career, though, like many developers, I switched to VS Code when it came out in 2015. I spend a lot of time at my keyboard, and by 2020, I was so crippled by RSI that I spent six months exclusively coding by voice (a blog article on the topic has made me more famous than I expected). A friend suggested I switch back to modal editing, either in VS Code or Vim, and it made a huge difference for me. The vast majority of vim keystrokes do not require you to hold down multiple keys with the same hand, something that really aggravates carpal tunnel syndrome.
• Performance: Most IDEs have some sort of “vi emulation” layer or plugin that allows you to reap some of the health benefits of modal editing without fully switching to a new editor. But waiting for VS Code to start up and load all the extensions you know and love has become a meditative exercise for many (or an opportunity to return to doom scrolling). In contrast, when I load my LazyVim configuration, it helpfully tells me how long it took to load: 56.98 milliseconds. To my slow, human eyes, it’s instant.
• Developer Velocity: This is debatable and subjective. Any tool is only as good as the trades-person who wields it, and I certainly know excellent coders who can really fly with their VS Code, Emacs, or JetBrains configuration. Still, I really believe that a finally-tuned Vim configuration can outpace any of them.
• Open Ecosystem: I have a lot of respect for how Microsoft treats open source software since Nadella took the reigns, but VS Code is showing increasing signs of proprietary lock-in (especially with its AI integrations). In contrast, the Neovim ecosystem is a vibrant open community, and innovative plugins arrive every week that would never be attempted in VS Code.

Why Neovim, specifically

If you decide to use Vim, you’ll quickly discover that there are two modern variations: Vim, and Neovim. Both are direct descendants of that original open source ’90s vim code. Neovim was forked from Vim in 2014 with a vision of refactoring and modernizing the codebase and feature set.

Both are actively maintained and both have the power to feel polished and modern, though neither actually leverage that power by default. Both have extremely strong plugin ecosystems, but Neovim has one killer feature there: It has introduced the Lua programming language for plugin development and configuration in addition to the native VimScript that its ancestor uses.

By itself, lua doesn’t make Neovim inherently better than Vim. However, where most Vim plugins also run on Neovim, the inverse is not always true, and there are best-in-class Lua plugins that only work with Neovim.

For the purposes of this book, your decision is already made for you: The LazyVim distribution only works with Neovim, so that’s where we’ll begin.

Introducing LazyVim

The chief problem with both Vim and Neovim is that while they have the capability to have the same (or better) modern editing experience of any other IDE, they don’t start out that way by default. Vim has a long tradition of maintaining compatibility with the outdated vi tool and Neovim has only marginally diverged from that tradition. When you first install Neovim, you get a pretty bland code editing experience.

When I switched back to Vim in 2020, after becoming used to the great functionality VS Code brought to the editor ecosystem, it took me two weeks to get my configuration where I wanted it and I tweaked it incessantly for months after. It came in at about 300 lines of Vimscript, which I later ported to around 250 lines of Lua code. To be fair, I’m a heavy customizer in general, and my VS Code configuration was actually longer than either of those! But I’ll happily admit that the VS Code out-of-the-box experience was much better.

I looked at several so-called neovim “distributions” (essentially, preconfigured setups). I won’t go into details of the comparison, but LazyVim is the clear winner by far, mostly because it balances a dead simple out-of-the-box experience with relatively easy customization and configuration.

An opinion: LazyVim flips the tables on VS Code and other IDEs. Where it is “possible to set up (Neo)Vim to be as powerful as VS Code”, LazyVim is, out of the box, more powerful and useable than VS Code. It is, of course, possible to “set up VS Code to be just as powerful as LazyVim”, but the key point is that LazyVim actually ships with more of the features that make editing delightful.

To be clear, LazyVim is Vim. The editing experience is identical. It’s not a new iteration or version of Vim in the way that Neovim is. Instead, LazyVim is a mindset; it starts with an agreement on what constitutes the best plugin configurations are for modern development, and a configuration that makes them work well together (keeping different plugins’ keybindings from conflicting with each other is one of the major painpoints when managing configurations manually).

But if you go into using LazyVim with the mindset that this experience will be better than any other editing experience you’ve worked with before, and accept that you will be retraining some keyboard muscle memory, you will find that it is extremely well-thought out. In my experience, it is exactly what a 2020s-era modal editing experience should be.

As with all software, your journey begins with installation. Click Next to get started.