binvim vs Helix

binvim and Helix are the two closest editors in spirit: both are single-binary, batteries-included TUI editors written in Rust, with LSP and tree-sitter built in and no plugin manager required to be productive. They part ways on one fundamental choice — how you edit — and on what each bundles beyond the basics.

+--

§ AT A GLANCE

binvim vs helix
// dimension
binvim
Helix
Editing model
Vim grammar · verb→object
Selection-first · object→verb
Single binary
~42 MB
yes
LSP built in
24 servers by extension
yes
Tree-sitter built in
compiled in
yes
Multiple selections
Ctrl-N, Sublime-style
core / signature feature
Debugging (DAP)
4 adapters · conditional + hit-count bp
~built in, experimental (lldb-led)
AI / Copilot
Copilot opt-in + AI pane
not bundled
Test + task runners
built in · 5 toolchains
not bundled
Plugin system
none, by design
Steel/Scheme, in development
License
BSAL · source-available
MPL-2.0 · open source
Maturity / community
new · v0.5.x
established · large community
+--

§ THE HONEST TAKE

who wins what

Where Helix is the better choice

Helix is more mature, has a much larger community, and is fully open source under MPL-2.0. Its selection-first editing model is genuinely excellent — you select a region and then act on it, which makes multiple selections and structural edits feel natural, and many developers prefer it to Vim's verb-first grammar. Helix is also further along on cross-platform polish, and its Steel/Scheme plugin system is in active development for those who will eventually want extensibility. If you like selection-first editing or want the safety of an established project, choose Helix.

Where binvim is the better choice

binvim keeps Vim grammar — verb-then-object operators, text objects, marks, registers, and macros — so Vim and Neovim users keep their muscle memory instead of relearning a selection-first model. It also bundles more out of the box: opt-in GitHub Copilot and a right-side AI assistant pane (:claude / :codex / :opencode), four turnkey DAP debuggers with conditional and hit-count breakpoints and debug-test routing, and integrated test and task runners across five toolchains. If you want those IDE pieces working immediately with Vim motions, binvim is built for exactly that.

Which should you pick?

Pick Helix if you prefer selection-first editing or value its maturity, community, and open-source licence. Pick binvim if you think in Vim grammar and want Copilot, an AI pane, multi-language debugging, and test/task runners bundled in. Both are single-binary and quick to install, so trying the other is cheap.

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

§ FAQ

binvim vs helix

What's the main difference between binvim and Helix?

The editing model. binvim uses Vim grammar (verb-then-object, e.g. ciw); Helix is selection-first (object-then-verb, Kakoune-style). Both are batteries-included Rust TUI editors, but binvim also bundles Copilot, an AI pane, four DAP debuggers, and test/task runners.

Does binvim use Helix's selection-first editing?

No. binvim deliberately keeps Vim grammar so existing Vim and Neovim users keep their muscle memory. Helix's selection-first model is great but is a different way of thinking — if you prefer it, Helix is the better fit.

Which has better debugging?

binvim ships four turnkey DAP debuggers (.NET, Go, Python, Rust/C/C++) with conditional and hit-count breakpoints and debug-test routing. Helix has built-in DAP too, but it is still experimental and currently lldb-led for Rust/C/C++/Zig, with other languages in progress.

Is Helix more mature than binvim?

Yes — Helix has a longer track record, a larger community, and an MPL-2.0 open-source licence. binvim is newer (v0.5.x) and source-available under BSAL. Choose Helix for maturity; choose binvim for Vim grammar plus bundled Copilot, AI, DAP, and test/task runners.

+--

§ MORE COMPARISONS

deep dives