Why I Switched from VS Code to Alacritty, tmux & Neovim

After mass of years using VS Code as my daily driver, I made a switch that fundamentally changed how I work. I moved to a terminal-based development environment built on Alacritty, tmux, and Neovim. Six months later, I'm not looking back – and I want to share why.

The Problem with VS Code

Let me be clear: VS Code is an excellent editor. It's what I recommended to every junior developer I mentored. The extension ecosystem is unmatched, the UI is polished, and it just works out of the box. For years, it served me well.

But somewhere along the way, I started noticing friction. Small annoyances that individually didn't matter, but collectively began to slow me down.

The startup time was the first thing. On smaller projects, VS Code opens quickly enough. But on larger codebases – the kind with hundreds of files and multiple workspaces – I'd watch the loading spinner for several seconds before I could actually start working. Those seconds add up when you're opening and closing projects throughout the day.

Then there's the memory footprint. VS Code runs on Electron, which essentially means you're running a Chrome browser instance just to edit text. On my machine, VS Code with a handful of extensions would regularly consume 500MB of RAM or more. That's a significant chunk of resources for what is fundamentally a text editor.

But the real issue was my workflow. I'd become dependent on the mouse. Click to open a file. Click to switch tabs. Click to access the command palette. Drag to select text. Every time my hand left the keyboard, I lost momentum. It sounds trivial, but when you're deep in a coding flow, those micro-interruptions matter.

And finally, feature bloat. VS Code offers an incredible range of functionality, but I was using maybe 20% of it. The rest was just noise – UI elements I never clicked, features I never enabled, extensions I installed once and forgot about.

I wanted something different. Something faster, more focused, and built entirely around the keyboard.

My Current Stack

My development environment now consists of three tools that work together seamlessly.

Alacritty is my terminal emulator. Unlike traditional terminals, Alacritty is GPU-accelerated, which means it offloads rendering to your graphics card. The result is buttery-smooth text rendering and near-instant startup. It launches so fast that there's no perceptible delay between pressing the icon and seeing my prompt. For someone who opens and closes terminals constantly, this responsiveness matters more than you'd think.

Alacritty is also intentionally minimal. It doesn't have tabs. It doesn't have splits. It doesn't have a built-in file browser. This might sound like a limitation, but it's actually a feature. Alacritty does one thing – render terminal output – and it does it exceptionally well. Everything else is handled by tmux.

tmux is a terminal multiplexer, which is a fancy way of saying it lets you manage multiple terminal sessions within a single window. Think of it as a window manager for your terminal. You can split your view into panes, create multiple windows, and organize everything exactly how you want. But tmux's real power lies in its session management – something I'll get into later.

Neovim is my text editor. It's a modern fork of Vim that addresses many of Vim's historical limitations while maintaining full compatibility with Vim's legendary modal editing system. The key difference is Neovim's configuration language: instead of the arcane Vimscript, Neovim uses Lua – a real programming language that's fast, readable, and incredibly flexible. This makes building and customizing your editor a genuine pleasure rather than a frustrating exercise in obscure syntax.

Together, these three tools form an environment that's fast, keyboard-driven, and entirely under my control.

Performance That Actually Matters

Let's talk numbers, because the performance difference isn't subtle.

VS Code, being an Electron application, inherits all the overhead of running a Chromium browser instance. On a typical project with a few extensions enabled, I'd see memory usage around 500MB to 800MB. With more extensions or larger projects, it could climb higher. This is just the reality of the Electron architecture – it trades resource efficiency for cross-platform consistency.

My terminal setup tells a different story. Alacritty uses around 30MB of RAM. Neovim, even with a full plugin configuration, hovers around 50MB. tmux adds negligible overhead. In total, my entire development environment consumes less than 100MB of memory – roughly one-fifth of what VS Code uses on a good day.

But memory is only part of the story. What I notice day-to-day is the responsiveness. Alacritty opens instantly – not "fast," but actually instant. There's no splash screen, no loading indicator, no pause. Press the shortcut, see the terminal. Neovim follows the same pattern. Even with dozens of plugins, it loads in milliseconds. File operations, search, navigation – everything responds immediately.

This might sound like obsessive optimization, but it genuinely changes how you work. When your tools respond instantly, you stop thinking about the tools. There's no mental buffer between intention and action. You think "I need to open that file," and the file is open. That frictionlessness compounds throughout the day.

Keyboard-First Development

This is where things get interesting, and honestly, where the real productivity gains live.

Vim's modal editing system takes a completely different approach to text manipulation than conventional editors. Instead of holding modifier keys while pressing letters (Ctrl+C, Ctrl+V, Ctrl+Shift+Arrow), Vim uses distinct modes. In normal mode, every key is a command. Press d to delete, w to move forward a word, combine them as dw to delete a word. Press i to enter insert mode, where you type normally. Press Escape to return to normal mode.

This sounds complicated – and initially, it is. But there's a method to the madness. Vim's commands are composable. Once you learn the basic building blocks, you can combine them in ways that feel almost like a language. d3w deletes three words. ci" changes the text inside quotation marks. gg=G re-indents an entire file. These aren't shortcuts you memorize; they're a grammar you internalize.

The payoff comes when the muscle memory kicks in. After a few weeks of consistent practice, you stop thinking about how to edit. Your fingers know what to do. Need to swap two lines? ddp – done before you consciously processed the thought. Need to change a function name everywhere in a file? :%s/oldName/newName/g becomes as automatic as typing the name itself.

What surprised me most was how this affected my relationship with editing. In VS Code, I'd often avoid making certain changes because the editing overhead felt high. Restructuring a file, reorganizing functions, cleaning up formatting – these tasks felt like work. With Vim, editing is so fluid that I actually enjoy refactoring. The barrier between thinking "this code should be cleaner" and making it cleaner has essentially disappeared.

Going back to a mouse-driven workflow now feels painfully slow. It's not that VS Code is slow – it's that constantly moving my hand between keyboard and mouse breaks the flow. Once you've experienced keyboard-only navigation, the mouse starts to feel like an interruption.

tmux: Sessions That Survive Everything

If Vim changed how I edit, tmux changed how I work.

The killer feature is session persistence. When you start a tmux session, that session lives on the server (or in the background on your local machine) independently of your terminal connection. You can detach from a session, close your terminal, shut down your terminal emulator entirely – the session keeps running. When you reconnect, everything is exactly where you left it. Open files, running processes, command history, cursor positions – all preserved.

This might not sound revolutionary until you experience it. I now start my workday by reattaching to yesterday's session. My project is already open. My test runner is still showing the last results. My server logs are still streaming. There's no "setting up my environment" phase – I just continue where I stopped.

The workflow implications extend to panes and windows. tmux lets you split your terminal into any configuration you want. I typically work with code on the left (taking about 70% of the screen), a terminal on the right for running commands, and sometimes a horizontal split at the bottom for test output or server logs. All of this is managed through keyboard shortcuts – I can create, resize, navigate, and close panes without touching the mouse.

But where tmux truly shines is remote development. SSH into any server, start a tmux session, and you have the exact same environment as your local machine. Same keybindings, same workflow, same productivity. If your connection drops – which happens more often than we'd like to admit – no problem. SSH back in, reattach to the session, and continue exactly where you were. No lost work, no restarting processes, no frustration.

I've had tmux sessions running for weeks on remote servers. Long-running builds, database migrations, log monitoring – all persisting across disconnections, even across my own laptop restarts. It's a level of resilience that traditional terminal usage simply can't match.

Full Customization with Dotfiles

Everything in my setup is configured through plain text files. Alacritty settings, tmux keybindings, Neovim plugins and configuration – all of it lives in human-readable files that I version control in a Git repository.

This approach offers benefits that compound over time.

Portability is the most obvious. When I set up a new machine, I clone my dotfiles repository, run a setup script, and within minutes I have my complete environment exactly as I left it on my previous machine. Every keybinding, every color scheme, every plugin – perfectly replicated. No manual configuration, no trying to remember how I set things up before, no "close enough" compromises.

Version control brings its own advantages. I can track every change I make to my environment over time. If a configuration change breaks something, I can revert it. If I want to try a new plugin, I can experiment on a branch without risking my stable setup. My environment has the same development rigor as my code.

But perhaps the most valuable aspect is intentionality. Nothing in my setup exists by accident. Every plugin, every keybinding, every setting is there because I explicitly added it to solve a specific problem. There's no bloat, no mysterious defaults, no features I don't understand. I know exactly what my tools do because I built the configuration myself.

Neovim's Lua-based configuration makes this especially powerful. Instead of wrestling with Vimscript's quirks, I write real Lua code to configure my editor. I can use conditionals, loops, functions – proper programming constructs. Complex configurations that would be painful in Vimscript become straightforward. And because Lua is fast, my configuration loads almost instantly despite its complexity.

My Neovim setup includes around 40 plugins, handling everything from syntax highlighting and code completion to Git integration and fuzzy file finding. Each one was added deliberately to address a specific need, and each one is configured exactly how I want it. The result is an editor that feels like it was built specifically for me – because, in a sense, it was.

Focus and Minimalism

There's a psychological dimension to this setup that I didn't anticipate.

When I open Alacritty and start Neovim, I see my code. That's it. No sidebar with file trees. No tabs competing for attention. No status bar icons, no notification badges, no breadcrumb navigation. Just a clean terminal window with syntax-highlighted text.

This might sound spartan, but it's actually liberating. Every element in a typical IDE is a potential distraction – something your brain has to process, even if only subconsciously. By stripping away everything non-essential, what remains is just you and the code.

I find myself focusing more deeply than I did in VS Code. There's less context switching, less visual noise, less temptation to click around exploring features I don't need. When I want to open a file, I use a fuzzy finder that appears, does its job, and disappears. When I want to see my file tree, I invoke it temporarily, find what I need, and dismiss it. Nothing persists on screen unless I'm actively using it.

This minimalism also makes me more intentional about my work. When there are no visual prompts suggesting things to do, I have to decide what's important. That sounds obvious, but in a feature-rich IDE, it's easy to get pulled into distractions – installing extensions, tweaking settings, exploring new features. My terminal setup doesn't offer those temptations. It does what I tell it to do, nothing more.

Works Everywhere

Perhaps the most practical advantage of a terminal-based workflow is its universality.

My setup works identically on my MacBook, on a Linux server I access via SSH, on a Raspberry Pi, inside a Docker container. Anywhere I have a terminal, I have my complete development environment. Same keybindings, same workflow, same productivity.

This portability isn't possible with GUI-based editors. VS Code has a remote development extension, and it works reasonably well, but it's still running VS Code's interface locally and connecting to a remote server. The experience is never quite the same as local development.

With tmux and Neovim, there is no local versus remote distinction. It's all just terminal sessions. If I can SSH into a machine, I can work on that machine exactly as I work locally. This has proven invaluable when debugging production issues, when working on machines that can't run heavy GUI applications, and when I simply need to get something done from an unfamiliar computer.

The skills transfer across my entire career as well. Vim keybindings work in countless other tools – many IDEs have Vim modes, and command-line utilities like less, man, and git respond to Vim-style navigation. The muscle memory I've built isn't locked into a single application; it's applicable across the entire Unix ecosystem.

The Learning Curve is Worth It

I won't pretend this transition is easy. It isn't.

Vim has one of the steepest learning curves of any commonly used tool. The first few days feel brutal – you're slower at everything, and basic tasks that took seconds now take minutes. You'll reach for keybindings that don't exist, get stuck in modes you don't understand, and occasionally lose work because you didn't quite grasp how buffers work yet.

tmux adds its own complexity. Session management, pane navigation, copy mode – each requires new mental models and muscle memory.

And configuration is manual. There's no GUI settings panel. If you want to change something, you edit a text file, look up the relevant option in documentation, and restart the application. It's powerful but not hand-holding.

I'd estimate it took me about two weeks before I was as productive as I'd been in VS Code. It took about two months before I was noticeably more productive. The investment is real.

But the returns are equally real. The speed and efficiency gains I've described aren't theoretical – they're my daily experience. The skills I've learned aren't tied to any single tool or platform; they're applicable across my entire computing life. And the environment I've built is genuinely mine, shaped by my preferences and optimized for my workflow.

For developers willing to invest in their tools, the terminal is worth exploring.

Conclusion

I'm not here to argue that everyone should abandon VS Code. It remains an excellent editor, especially for those who prefer a polished out-of-the-box experience, for teams that need standardized tooling, or for developers who simply have other priorities than optimizing their text editing efficiency.

But if you're the kind of person who cares about speed, who wants full control over your environment, who works across multiple machines and platforms, or who simply enjoys mastering powerful tools – the terminal is worth your attention.

Alacritty, tmux, and Neovim aren't just tools. They're a different philosophy of development. One where you build your environment rather than accept defaults. Where you invest in skills that compound over time. Where every keystroke is intentional and every response is instant.

Once you're in, you'll wonder why you ever worked any other way.