Helix may be what you need

Helix or Neovim? Neovim or Helix? That is the question. A bold one, sure—but really, it’s just one tiny debate in the massive world of text editors.

I previously wrote why I’ve chosen Neovim as my text editor and this post is not intended to pretend Neovim is superior to any other options, nor to convince anyone to move to it. No, this post is the result of a discussion with alecsargent , a long time Helix user who is currently considering Neovim as a potential viable option after having tried Vim long time ago.

At some point, many terminal-centric Linux users run into the same dilemma: Do I want to invest time and cognitive effort into building my ideal text/code editor with Neovim and rework my muscle memory, or am I content with the features offered by Helix, accepting its hardcoded defaults?

This isn’t just about picking a text editor. It’s about philosophy, commitment, and how much control you want over your tools.

The elephant in the room: “good enough” vs “build it yourself”

Helix is designed to be a good enough editor out of the box. Its strength lies in stability, sane defaults, and a zero-configuration approach. You install it, open a file, and immediately get a polished experience.

Neovim, on the other hand, is a framework. It’s delivered as a blank page, a foundation. It could be seen as the Archlinux of text editor. If you need a feature, you need to install it first.

Each text editor has chosen to put the accent on one aspect: flexibility or simplicity. Neither approach is wrong, but they are very different commitments.

My personal bias (and I won’t pretend otherwise)

To me, Linux embodies freedom in every sense of the word. Freedom to inspect, tweak, replace, and reshape every part of the system. Freedom to adapt the machine to me, not the other way around. That philosophy spills over into my tooling choices.

I’ve reached a point where I can’t seriously consider a tool — no matter how good — if it forces hardcoded keybindings on me. That freedom of choice exists thanks to countless developers building alternative tools that may solve the same problem differently, but allow users to pick what fits their workflow.

I have no issue investing effort and changing habits if I can envision a benefit to my future workflow. I always try to project myself forward: what might I be interested in next year? In five years? How will this tool scale with me?

Over time, I’ve tried many terminals, window managers, text editors, browsers, and even keyboard layouts. Some tools demanded serious commitment to install, configure, maintain, and always required changes in habits. This journey is far from over.

A common misconception

It’s frequent to hear that, because Neovim relies on plugins, it’s bloated, slower, and bug-prone.

Let’s break that down.

Plugins are just features

Plugins are simply feature implementations added to a minimal core. Everything Helix ships with can be seen as a collection of plugins that are pre-packaged and hard-wired into the editor.

Performance impact is negligible

A well-designed plugin adds microseconds to a few milliseconds. Even large plugins may add a few tens of milliseconds.

Are we really judging tools based on delays that are below human perception? Especially when those plugins often enable features the competing editor doesn’t even offer?

Plugin stability is good

In my experience, plugin bugs are rare. When they do happen, they’re often fixed within hours or a day. Yes, plugins are maintained by volunteers, and abandonment is always a risk, but alternatives usually exist.

Also, plugin maintenance is largely a non-issue thanks to Neovim plugin managers. Many plugins require no configuration at all. You add them once and forget about them.

Feature comparison

If you’re reading this, you probably already know why Helix is good. So instead of listing everything, I’ll focus only on areas where Neovim and Helix meaningfully differ.

Configuration: Neovim’s biggest weakness

Helix wins this one — no contest.

Neovim configuration is not friendly. Its documentation doesn’t help either: everything is exposed, including low-level technical details meant for core or plugin developers. That alone is a huge barrier to adoption.
Plugin configuration makes it worse, since plugins often expose developer-centric APIs and workflows.

Neovim is truly a tool you build yourself. It’s like handing a box of LEGO bricks to a kid and saying, “Create something.” That’s intimidating, but also empowering.

The upside? Once you understand the core concepts, everything suddenly clicks and becomes much easier to reason about.

Interestingly, Lua helps more than you’d expect. I knew nothing about Lua and still managed to create a TaskWarrior-Neovim integration from a single online document. I haven’t turned it into a plugin yet — but that’s on me.

Customization: where Neovim shines

Neovim lets you customize everything:

• UI elements (statusline, command line, tabs — what’s visible, where, and how)
• Pickers and selectors per task
• Custom commands and autocommands
• Hooks (on save, on enter, on events)
• Floating windows for entirely new workflows

The list is endless.

A word on muscle memory

Yes, switching editors hurts. I went through it too. But most default Neovim keybindings can be translated to plain English, which helped a lot (i.e. “daw”: delete around word).

Ironically, I found Helix’s arbitrary defaults harder to internalize over time, precisely because they’re hardcoded and can’t be reshaped around your mental model.

Session management

Helix offers automatic, directory-based sessions. Reopen the editor from the same folder and you’re back where you left off.

Neovim takes a different approach: sessions are more flexible, more customizable, and not tied to directory semantics.

Buffers manipulation

I’ll be honest: my Helix experience isn’t deep enough to confidently state the exact differences here. That said, a sentence I’ve seen repeatedly feels accurate: “Helix can do <your_feature>, but it’s not as feature-rich as Neovim.”

Embedded terminal

This may be the one Neovim feature Helix users seriously miss. Personally? I rely on tmux pop-ups instead.

Macros

Neovim supports full macro recording and playback via registers. This is incredibly powerful for repetitive editing tasks.

Helix has repeat functionality and command history, but no traditional macro system. I don’t use macros often, but when you need them, they’re a massive productivity boost.

Structural editing and LSPs

Structural editing is often cited as a Helix strength, but most comparisons pit Helix against minimal Neovim setups.
With nvim-treesitter and nvim-treesitter-textobjects, Neovim can actually go further.

In Helix, you still install LSPs manually. Neovim, with tools like Mason, makes adding LSP support a one-line change.
Nonetheless, LSP installation in Neovim remains scary. That’s true at first glance, but it’s far simpler than it appears. The real issue is presentation: too many technical details upfront, with no acknowledgment that LSPs are incredibly useful even for beginners.

Git support is another gap: Helix offers basics, Neovim offers full UIs and workflows.

Multi-cursor

I don’t have much hands-on experience here, but Helix is consistently reported as better in this area.

Notes systems

This may not matter to you, but Neovim’s flexibility allows for fully custom note systems (Obsidian/Zettlekasten -like), integrated with projects, Git, and external tools.

Helix doesn’t offer anything comparable.

Wrap-up

The beauty of Linux: Variety. Choice. Trade-offs.
In the end, it’s always a mix of design philosophy, feature set, learning curve, and willingness to change habits. For years, I thought advanced text editors were only useful for developers. I was wrong.

In the end, no text editor is superior, and there’s never a unique answer to this frequent question: “Which app is better for…”. Actually, one should prefer to ask “Which apps do you recommend (and why) for…”. Apps just answer different questions and users’ needs.