Every few months the same question surfaces in developer forums: “Which IDE should I commit to?” The debate is exhausting because the premise is wrong. Instead of choosing a platform and living inside its walls, you can build a toolchain, not a platform—a hand-assembled collection of CLI tools and Language Server Protocol servers that work together for any language, any project, and any future editor. This is not a niche workflow reserved for terminal purists; it’s a practical philosophy that gives you more power, less bloat, and total ownership over your development environment.
The IDE Monoculture Problem
We’ve seen this movie before. Eclipse swallowed Java, Visual Studio swallowed .NET, and then VS Code came for all of us. VS Code is a remarkable piece of engineering, but it’s also a platform. It wants to be the place you run your terminals, review your diffs, manage your containers, and log your issues. Every year it grows more ambitious, and every year the extension ecosystem gets heavier: bundles that consume gigabytes of RAM, telemetry channels phoning home, and a constant stream of “recommended” workflows that shift with the wind.
The problem isn’t that these platforms are bad. The problem is that they’re sticky. If you find a faster linter or a smarter language server, you can’t simply swap it in—you wait for an extension to be released, approved, and maintained. That model is baked into the platform mindset. The toolchain mindset, by contrast, treats every component as replaceable.
Best-of-Breed: One Tool, One Job, Composed
The Unix philosophy got it right decades ago: write programs that do one thing well and design them to work together. A modern toolchain applies that logic to the entire editing experience. Instead of downloading a monolithic IDE, you assemble a pipeline:
- A light editor core that’s fast at text manipulation and knows keybindings—Neovim, Helix, or even a stripped-down VS Code.
- Language servers delivering the actual intelligence: type checking, autocomplete, hover docs, and refactors, all defined by the LSP protocol.
- CLI search and transform utilities such as ripgrep, fd, fzf, and jq for invisible speed in large projects.
- Formatters and linters that work as standalone executables—prettier, ruff, eslint, gofmt—not as IDE plugins.
- Git tooling that composes with the rest: lazygit, delta, git-branchless.
Because each tool respects standard interfaces—stdin, stdout, exit codes, JSON—the system becomes far more than the sum of its parts. Trade Neovim for Helix tomorrow, and your language servers and linters keep working unchanged. That’s the best-of-breed advantage.
The Quiet Rise of the Language Server
Language Server Protocol is the glue that makes this possible. After Microsoft opened the protocol in 2016, the entire industry converged on a standard way for editors and language intelligence engines to talk to each other. By now, every serious editor speaks LSP—including VS Code itself. That single fact changes the calculus of IDE choice more than any new feature launch.
Here’s the key insight: the LSP server that powers Python IntelliSense in VS Code is the exact same server you can connect to Neovim, Helix, Emacs, or a bare terminal edit loop. So when you ask “which IDE is best for Python”, you’re asking the wrong question. The better question is: “which language server gives me the most precise errors?”
- Python: pyright or basedpyright for strict, fast type-checking.
- Rust: rust-analyzer—the gold standard of language servers.
- TypeScript / JavaScript: typescript-language-server or vtsls with strict mode.
- Go: gopls, a model citizen of the language server ecosystem.
- Lua: lua-language-server, surprisingly sophisticated for its niche.
Each of these wires up in a few lines of config. No extensions, no marketplace ratings, no subscriptions. Just an executable on your PATH and a small block telling your editor core when to launch it.
Assembling Your Own IDE: A Practical Recipe
The process is repeatable across languages and projects. Here’s how to think about it.
Step 1: Pick a Neutral Core
Your editor core doesn’t need to be “the best” at anything except editing text and running external tools. Neovim is the natural choice for many because of its embedded Lua runtime and native LSP client. Helix offers a refreshingly minimal config and sensible defaults. The smaller the core, the fewer layers between you and the actual processing. When you pick an editor that merely orchestrates the tools, you stop being trapped in its opinion of how a language should feel.
Step 2: Wire LSP Servers to File Types
In Neovim, a single Lua block can launch multiple language servers automatically based on file type. You don’t need one extension per language. The client handles hover, definition, formatting, and rename, while your keybindings stay identical no matter the project. To add a new language: download the server binary, write a three-line config, and start working. This is the same power that a massive IDE delivers, but without the platform tax.
Step 3: Bring CLI Power Tools Along
The terminal is the missing piece that turns a text editor into an environment. fzf gives you fuzzy file navigation and even fuzzy grep results. ripgrep searches entire monorepos at speeds that make the CPU blush. fd finds files and directories without excess output. jq prunes JSON responses from your LSP server, an API debugger, or a test runner. These utilities are editor-agnostic, meaning they’ll serve you in any context, for years.
Config as Code: Your Toolchain Follows You
Once your setup lives in plain-text config files, you can version it. Many developers now keep a “dotfiles” repository with the full environment: editor config, language server setup, linter settings, and shell aliases. On a new machine, it’s a single clone and install script away. Nix users take it further, defining the entire toolchain—editor core, all LSP servers, formatters, and even the language toolchains themselves—in a reproducible dev-shell definition.
This is a powerful shift in ownership. A platform profile exports a few JSON settings and suggests you install extensions manually. A toolchain repository is a living project you control, test, and review. When something breaks, you know exactly where to look: your git history, not a mystery marketplace update.
Where the Toolchain Approach Doesn’t Shine
It would be dishonest to pretend there aren’t gaps. Deep visual debugger timelines, mobile UI storyboarding, drag-and-drop interface builders—those genuinely benefit from tight platform integration. If your daily work depends on those features, keep a graphical IDE around for the moments it helps. The toolchain approach isn’t a religion; it’s a toolkit. For everyday coding, reading, and refactoring, the advantages are impossible to ignore: faster startup, fewer crashes, no telemetry, and a config that speaks your own language.
And whenever the LSP ecosystem fills in another gap—and it keeps filling them—the modular approach only gets stronger.
The Better Question
In the end, the IDE debate is less about tools and more about mindset. A platform asks you to adapt to its shape; a toolchain adapts to yours. By combining LSP servers, fast CLI utilities, and a light editor core, you get the same language intelligence as a monolithic IDE, with fewer layers of indirection and a setup you can carry into every future project. So when the next “which editor is best?” thread appears, you’ll already know the answer is a better question: what should you build it from?
