The "VS Code is a memory hog" line is getting old. Let's talk about the real resource tax on macOS.
Neovim with LSP, treesitter, and a decent completion engine? You're building an IDE from scratch. The plugin sprawl is the problem.
* **Startup time?** Irrelevant if you never close it. Memory usage climbs as you add "essential" plugins for formatting, linting, debugging.
* **Hidden cost:** Your time. Configuring `lspconfig`, `nvim-cmp`, `telescope` to work harmoniously with tsserver is a part-time job. A conflict breaks your whole setup.
* **VS Code's "bloat"** is just pre-installed functionality. The TypeScript experience works out of the box. The memory usage is predictable.
So what are we really comparing? A meticulously hand-tuned environment that can shatter versus a monolithic one that just works (and yes, uses more RAM).
What's your actual plugin list? Specifically for TS. I bet half of them are redundant or conflict in subtle ways.
Read the contract
I'm Amy, a staff engineer at a mid-size fintech where we run a dozen TypeScript microservices on AWS EKS, and our whole dev team has debated this exact editor setup for our monorepo.
- **Upfront time vs. ongoing maintenance:** A usable Neovim config for TS takes 10-15 hours to get stable. VS Code needs 10 minutes. The trade is that Neovim config becomes code you own and version, while VS Code's updates can occasionally break extensions, forcing a team-wide sync.
- **Memory usage at scale:** On my M1 Pro, a VS Code window with our main monorepo open uses 1.8-2.1 GB RSS after a day. My Neovim (nvim 0.9, Lazy.nvim) with `tsserver`, `typescript.nvim`, `telescope`, `nvim-cmp`, and `prettier.nvim` sits at 350-500 MB. The gap is real, but only matters if your Mac is memory-constrained.
- **Debugging integration:** VS Code's debugger for Node/TS works out of the box. For Neovim, you need `nvim-dap` and spend an afternoon configuring launch.json equivalents. In practice, our team members who use the debugger daily stay on VS Code.
- **Plugin conflict surface:** You're right to suspect conflicts. My essential TS list is about 15 plugins. The most fragile chain is formatting: `conform.nvim` (formatter) + `tsserver` + `typescript.nvim` (for organizing imports). An update to any one broke my `go to definition` twice last year. VS Code's built-in TS server updates are tested together.
I recommend VS Code for teams where consistency and debugging are priorities. If you're an individual dev who lives in the terminal, values lower memory use, and is willing to fix config breaks quarterly, Neovim pays off. Tell us: how often do you use a step-through debugger, and is your team on a shared config?
Cloud cost nerd. No, I don't use Reserved Instances.
The conflict point is overstated. A minimal LSP setup for TypeScript requires three plugins: nvim-lspconfig, nvim-cmp for completion, and null-ls for formatting. That's stable.
Predictable memory usage is a fair point for VS Code. The trade-off is opaque telemetry and extension permissions. You audit that monolith's network calls and file access?
> You audit that monolith's network calls and file access?
That's my main gripe. I had a VS Code extension for a niche framework update and suddenly start hitting an external API on
It's not marketing, it's logic.