Leaving VSCode

A few years ago I would have identified as a VSCode power-user and evangelist. It felt like an instrument I had mastered through custom keybindings and practiced motions. I loved how it felt like how my web browser felt, was programmed like how my web browser was programmed, and had a rich plugin/tooling ecosystem that could turn it into a full IDE for a given language at a button click.

A few things spoiled that for me:

  1. A colleague shared this article ‘Visual Studio Code is designed to fracture’ which argues (compellingly in my opinion) that VSCode is a tool/ecosystem designed to fracture open-source development communities and funnel developers towards Microsoft products (GitHub, Codespaces, etc…). The article is really worth a read but a few relevant points in particular:
    • VSCode = VSCodium (the truly open-source part of VSCode) with a bunch of Microsoft Telemetry added + access to Microsoft’s VSCode Extension Marketplace
    • only VSCode and not the open-source VSCodium or its derivatives can legally use Microsoft’s VSCode Marketplace for Extensions
      • Most of us understandably don’t see this in the fine-print and become dependent on Microsoft’s proprietary products (namely; their extension marketplace and proprietary software leveraged by extensions), thinking we’re using open-source tooling
    • ‘fracture by design’ strategy:
      • MS builds the best (proprietary) extensions which become the default for most developers, or switches the default implementation used by extensions that have already gained mass user-bases from open-source ones to proprietary ones (e.g. Pylance).
      • license restrictions prevent those extensions from being used by 3rd parties
      • competitors can’t offer products with comparable extensions
      • everyone ends up using VSCode; funneling user data to Microsoft and nudging users towards Microsoft products
      • see the article for a few examples
  2. I also then remembered how mad I was that Microsoft killed Atom which had been my main editor before VSCode.
  3. A proprietary part of the Python Extension broke:
    • I was deeply dependent on the Python Extension for VSCode which used the proprietary Pylance software
    • An update caused Pylance to stop working on the machine where I was doing development and my only recourse was to revert to an old version of the extension
    • Months passed and newer versions still wouldn’t work, so I was stuck pinning old extension versions and forgoing security updates with no way to investigate or fix it myself since Pylance is closed-source.
  4. Slow installs:
    • I was doing development on remote servers at the time.
    • those servers would destroy/recreate every day, so every day I’d have to re-install VSCode Server + all my extensions
    • that would take about 15 minutes per day…
  5. Resource footprint:
    • I regularly like to have somewhere between 4-6 code bases or git worktrees open concurrently in different windows
    • a standard-issue public service developer laptop struggles to keep up.
  6. VSCode got kind of boring?
    • It seems like every new editor since ~2020 is some fork of VSCodium layered with some company’s license, branding, telemetry, and tooling (Cursor, Windsurf, Positron, etc…)
    • This editor monoculture is getting a bit boring? Or giving a false impression that we’ve converged to some editor utopia/singularity.
    • I’m nostalgic for when technologies were perhaps more bespoke (artisanal?); flip-phones with weird hinges in the early aughts, notepad/vim/atom/emacs/sublime/visual studio/eclipse/jetbrains editors, commercially-failed drum machines of the 80s repurposed for techno, etc…

Selecting a New Editor is Hard

My criteria for an editor:

  • free and open source, with an extension community that is also committed to FOSS (and not dependent on a proprietary marketplace…)
  • no shady telemetry
  • support for any languages
  • decent plugin ecosystem
  • not too disruptive of my existing workflow?
    • kind of failed at this one tbh

After cutting out VSCode forks, paid editors, and those bespoke to certain languages, I basically saw Emacs and Neovim as my 2 options.

I decided to try Neovim - not a particularly well-informed decision to be honest. I don’t know Emacs well enough to compare the two meaningfully but the main attractors of nvim for me were:

  • learning it would make me competent in vim which is likely installed on any server I may need to remote into
  • developed on a modern language (lua) which I presumed would make it easier to configure and write my own plugins some day
  • the goal of keeping keystrokes close to the home-row was appealing

Why Neovim?

It’s a lot of fun; coding can become more pleasurable. Once you get used to bindings, shortcuts, macros, etc…, coding feels like playing an instrument. I think you can get this feeling in other editors too but the rabbit hole goes pretty deep with neovim.

It forces you to develop a better understanding of how the tools that we rely upon daily actually work, because you have to configure them to some extent: code navigation works with LSP, syntax highlighting is done by treesitter, fuzzy-finding relies on projects like ripgrep, etc…

Maybe someday you’ll be more efficient in nvim than other editors? I don’t think this is a good primary reason. It definitely takes a while before you see a positive return on learning new navigation keys and keybindings. For me, it took about 3 months before I was competent, maybe 8 months to a year before I was faster (I think?) than I was in VSCode.

A few other tangible advantages:

  • installs extremely fast (the ~15 mins a day I was waiting for VSCode + extensions on my dev server became about 30s)
  • small resource footprint (I regularly run 5-10 instances concurrently on 16GB RAM with no issues)
  • being terminal-first is appealing to some developers.

How to Get into Neovim

A few practical tips:

Start Small

Accept that it will be frustrating and slow

  • don’t try to do your most critical work in neovim if you’re just getting started
  • don’t try to switch during an intense period/push at work
  • start easy: move non-critical text editing to neovim to start and get used to navigation and basic things:
    • most developers I’ve worked with have maintained some collection of plain-text files for notes or todo lists: start managing/editing these files with neovim
    • I was journaling at the time: I switched this to neovim too
    • start version controlling or at least backing these up because you might accidentally delete something by fumbling swap files
  • when it starts getting frustrating, switch back to your more comfortable editor.
    • It’s very humbling going from a power-user of VSCode to struggling to copy/paste a line
  • use neovim when you can afford the luxury of patience:
    • have to be in a situation such that if something trivial isn’t working like finding files, renaming symbols, etc… you have the time/space to say ‘this clearly isn’t working, how can I fix it in my nvim config’
    • AI-assisted development makes this way easier by lowering the barrier/mental energy needed to fix an issue with your editor config

Maybe don’t start with a full-fledged nvim starter?

There are a few (really good!) neovim config starters which configure neovim as a full-fledged IDE out-of-the-box.

I tried starting with NVChad originally; it configured everything for me and gives a fantastic neovim setup, but I had no clue how anything worked or stitched together.

I didn’t understand what parts of my nvim configuration came from plugins vs. NVChad vs. built-in neovim.

Eventually I removed it and started from ‘scratch’ (well, with lazy.nvim as a plugin manager).

Some Core Nvim functionality I’d start with

  • If you’re using AI-assisted development, get AI to help you write your config
    • if you’re trying to work on a codebase and something in your editor isn’t working, it can be very disruptive to have to entirely switch context to writing lua in your neovim config to resolve it
    • if you can vibe-code a fix (e.g. ‘lsp navigate to functionality isn’t working - fix it’) instead of switching contexts entirely, you’ll be more likely to incrementally fix/improve your nvim config
  • get a package manager such as lazy.nvim
  • make sure yank is integrated with your system clipboard. By default yanked text doesn’t go to your system clipboard; vim.opt.clipboard = "unnamedplus" fixes this
  • make sure you can navigate to files easily:
    • telescope.nvim can give file finding across your codebase (akin to ctrl+p in VSCode) and live-grep/fuzzy-finding
  • add a file explorer such as nvim-tree
  • add a terminal buffer plugin such as toggleterm.nvim
  • get Language Servers working

Use the Vimium Browser Extension

Vimium adds vim-like controls to your browser so you can mostly operate your browser using vim keyboard shortcuts and not need to touch your mouse.

This helps with 2 things:

  • get more comfortable with navigation and other basic controls
  • more parity between your editor and your browser where you’re probably looking up documentation, testing changes, etc… - you don’t need to switch mental modes as much when your cursor is focused in nvim vs. your browser.