Vim wants you to control, VSCode wants you to consume • Buttondown

Computer Things

August 18, 2026

Vim wants you to control, VSCode wants you to consume

The two sides of the editor divide, and why I'm on the losing side.

Newsletter updates were sporadic in July because of two weddings, two conferences (with two different talks!), and finishing Logic for Programmers. Huge thank you to everybody who bought a copy, as well as for your patience with the schedule. There's some podcast appearances, a conf talk, and a book sale at the end of this post.

Newsletter updates will be sporadic in August because I just started my Developer Educator job at Antithesis. I'll have less time to write because I'll be working 40 hour workweeks, about 8 hours of which being actual work and the other 32 being bashing my head against NixOS.

NixOS is the standard developer OS at the company. It's also a notoriously difficult distro to learn even for Linux heads, and I'm coming from Windows. The only way I am going to get anywhere is to go all in and commit fully to the NixOS philosophy.1 For one, I'm seeing how long I can last without my customary 2000-line Neovim config.

Which immediately raises the question as to why I have 2000 lines of Neovim config. It's because Vim2 (and Emacs) think of configuration in a very different way than more popular editors do.

Control and Consumption

Say we want to make ctrl+n to save the current file. In VSCode, you put this in keybindings.json:

"key": "ctrl+n",<br>"command": "workbench.action.files.save"

In Neovim, you put this in init.lua:

vim.keymap.set('n', '', function() vim.cmd.write() end)

Now, a couple of differences to see. First, the VSCode example is invoking a fixed, built-in command, while Neovim can bind an arbitrary function. Second, in VSCode you edit a static configuration file with static data, while in Neovim you execute a command that edits the running editor state. In fact, it doesn't even need to be in a configuration file: you can add a new keymap directly from the command line. Though you'd probably instead do that command in the OG Vim way:

map c-n> :wCR>

And that does something different than a function: it makes pressing ctrl+n mean "do whatever typing :w and pressing Enter would do." In default Vim that is the same as saving a file, but if you remapped : to o then it would instead do the equivalent of ow, which would type the character w on its own line. 3

In other words, Vim gives you incredible programmatic control over the state of the editor. Want to make typing ;r paste from the clipboard? Easy. Want different setting options in normal and insert mode? Go ahead. Want to make "writing a file" do something different during a full moon? You could if you want. 4

Now, you can do some amount of customization in VSCode, especially with multicommands, but for the majority of complex stuff you need to write a plugin. And making a plugin in VSCode is a much heavier process than making one in Neo/Vim. If you want to make a command that prints the word count, you have to 1) learn TypeScript, 2) scaffold a special VSCode extension project, 3) define a wordcount function, 4) register the mycode.wordcount command, 5) add mycode.wordcount as a contributes record in the extension manifest, 6) package or publish your extension, and 7) import the extension. It's very clear that the plugin system is not meant to let you tweak in a bit of functionality, but rather to let specialists produce complete plugins for other developers to consume. And since so much of the advanced functionality of VSCode is only possible through plugins, this limits the control the average user has over their environment.

Neovim also has plugins, but they can't do anything you couldn't already do in your default config. Admittedly, some bits of the APIs are meant specifically for plugin specialists, but they're still documented and available for your personal configuration. You never know what someone's gonna need!

In summary:

VSCode has a two-tier system, where plugin makers make plugins that users consume. The plugin has more power than the user. Most users aren't expected to make their own extensions.

Vim has a one-tier system: the user can do anything a plugin can. Everybody is always able to extend the system and have as much control as they want.

Most people should be consumers

Confession: this all is unintentionally a little ragebaity. "Consumer" is a dirty word in software. A consumer is somebody at the mercy of a producer's decisions. I think there's even a connotation of passiveness in being a consumer. It sort of starts leaning into a moral judgment: developers should use Neovim because it gives them control.

But, and this is intentionally a little ragebaity, it's the other way around. Most developers are better off sticking with the consumer model and only switching to a control-editor if they really, really want to. 5

First of all, learning to configure and extend Vim is...