From VS Code to Helix

Original Article ↗ Hacker News Discussion ↗

Switching Costs & Muscle Memory

  • Many feel locked into Vim/Neovim because it’s everywhere by default and Vim keybindings exist in almost every IDE.
  • Helix’s “almost Vim but not quite” bindings are a blocker: people fear corrupting decades of muscle memory.
  • Some wish Helix had a fully vi-compatible mode; “evil-helix” helps but still diverges enough to be frustrating.
  • Others report that switching (from Sublime, Vim, VS Code) was rough for a week or two but ultimately fine once they forced themselves to go “cold turkey.”

Helix vs Vim Editing Model

  • Central debate: Helix’s selection-then-action model vs Vim’s action-on-motion.
  • Pro-Helix side: default multi-cursor and home-row-centric bindings are more intuitive and ergonomic, and always seeing the selection is a “game changer.”
  • Skeptical side: Vim already has Visual mode (also select-then-act); differences feel incremental, not revolutionary.
  • Some see Helix as “just stripped-down Vim/SpaceVim” and question its distinct value; others say the value is being a clean, modern terminal IDE with good defaults.

Configuration, Plugins & LSP

  • Helix is praised for strong out-of-the-box behavior (LSP, fuzzy finding, treesitter-like navigation, etc.) without plugin hunting.
  • Criticism: calling it “no config” is misleading—you still need to install LSPs and edit a TOML; some think common languages should work fully by default.
  • Compared to Neovim’s “plugin hell,” Helix’s limited extensibility is seen as both a relief (less fragility, smaller attack surface) and a drawback (missing Copilot, Git blame, scripting, rich debug/quickfix flows).

Comparisons with Other Editors

  • VS Code: loved for extensions, GUI niceties, remote dev, Jupyter, GitLens; some use it as “Vim with better UX” via Vim keybindings.
  • JetBrains: unmatched static analysis and refactoring but heavy and resource-hungry; some fear future enshittification/paywalls.
  • Zed: praised for speed and Helix-like keybindings, but criticized for login flows, GPU requirement, VC backing, and weaker Helix-mode maturity.

Ergonomics & Keyboard Layout Tangent

  • Keyboard-layout analogy: sticking with Vim/VS Code is like sticking with QWERTY for universal availability.
  • Long subthread on Dvorak/Colemak, ergo keyboards, and RSI: general theme is that ergonomics and pain reduction can justify retraining, but switching costs are highly individual.

Politics, Licensing & Big Tech Dependence

  • Some support moving away from Microsoft tooling (VS Code, GitHub, Copilot) for political/sovereignty reasons; others mock “half-measures” and nostalgia for Stallman-style zeal.
  • Noted that the commonly used VS Code build is not truly “open source” under its official license; Codium is mentioned implicitly as the FOSS alternative.
  • Counterpoint: VS Code’s ecosystem and forking potential make it a pragmatic choice even for those wary of Microsoft.

Limitations, Bugs & Missing Features in Helix

  • Reported gaps: no built-in terminal emulator/quickfix-equivalent story, weaker project-wide find/replace, incomplete debugging (DAP) docs, no Copilot-quality AI integration, limited scripting/extensibility.
  • Specific annoyances: long-standing issue around jj-style insert-mode escape without a timeout; some users hit small friction points repeatedly and revert to VS Code.
  • Despite that, many praise Helix’s speed, simplicity, and “just works” feeling, and some have permanently switched from Neovim or JetBrains.