binvim vs Neovim

binvim and Neovim both descend from Vim's modal grammar, but they answer opposite questions. Neovim is a platform you assemble — a fast core plus a Lua config and a plugin manager you wire into an IDE. binvim is a finished editor you install — LSP, tree-sitter, four DAP debuggers, Copilot, and test/task runners already linked into one ~42 MB binary, no plugin manager.

+--

§ AT A GLANCE

binvim vs neovim
// dimension
binvim
Neovim
Editing model
Vim grammar, native
Vim grammar, native
Setup to a working IDE
install · ~40-line TOML optional
Lua config + plugins, often 100s–1000s of lines
Plugin manager
none
lazy.nvim / packer (you choose)
LSP
built in · 24 servers by extension
~nvim-lspconfig + mason
Tree-sitter
compiled in
~nvim-treesitter, per language
Debugging (DAP)
4 adapters built in
~nvim-dap + per-language wiring
AI / completion
Copilot opt-in + AI pane built in
copilot.lua / cmp / blink plugins
Test runner
built in · 5 toolchains
~neotest + adapters
Implementation language
Rust
C + Lua
Extensibility ceiling
fixed, curated feature set
effectively unlimited
Upgrade risk
nothing to break
plugin updates can break your config
+--

§ THE HONEST TAKE

who wins what

Where Neovim is the better choice

Neovim's whole point is that it bends to you. With a plugin manager like lazy.nvim and a Lua config you can build almost anything — a bespoke dashboard, a niche language workflow, a custom statusline, an integration nobody else has shipped. The ecosystem is enormous and mature, the community is the largest in the modal-editor world, and Lua makes the editor fully scriptable. If you enjoy tinkering, depend on a specific plugin, or want a setup that is uniquely yours, Neovim is the right tool and binvim will feel constraining.

Where binvim is the better choice

binvim is for the developer who opened their Neovim config last week and felt tired. There is no plugin manager, no Lua, and nothing to break on upgrade. Tree-sitter parsers, 24 language servers wired by file extension, four DAP debuggers (.NET, Go, Python, Rust/C/C++), opt-in GitHub Copilot, an AI assistant pane, and integrated test and task runners across five toolchains are all linked into a single ~42 MB binary. Configuration is an optional ~40-line TOML file; with none, sensible defaults apply. You get IDE features now, not after a weekend of assembly.

Which should you pick?

If you want a platform to customize endlessly and you treat your editor config as a hobby, pick Neovim. If you want a finished, opinionated editor that already speaks Vim grammar and ships the IDE batteries in one binary, pick binvim. Your motions transfer either way — operators, text objects, registers, and macros work the same — so trying binvim costs you almost nothing.

$brew install bgunnarsson/binvim/binvim all install methods →
+--

§ FAQ

binvim vs neovim

Is binvim a fork of Neovim?

No. binvim is written from scratch in Rust and shares no code with Neovim or Vim. It re-implements Vim grammar as a native modal editor, but it is not a Neovim distribution, plugin, or fork.

Can I use my Neovim plugins in binvim?

No, by design. binvim has no plugin manager and no Lua runtime. The features people usually reach for plugins to get — LSP, tree-sitter, completion, formatting, a file tree, fuzzy pickers, four DAP debuggers, Copilot, and test/task runners — are compiled into the single binary instead.

Will my Vim/Neovim muscle memory work?

Yes. binvim implements classic Vim grammar — verb-then-object operators, text objects, marks, registers, macros, and dot-repeat — so the core motions transfer directly. There is no config or plugin setup to port, because there is none.

When should I choose Neovim over binvim?

When you want maximum extensibility: a bespoke setup, niche plugins, Lua scripting, or the largest editor ecosystem and community. binvim trades that ceiling for zero plugin maintenance.

+--

§ MORE COMPARISONS

deep dives