#editors 

I’ve previously written about how much I like working with vim as my primary text editor. I have been using it for over a decade and it has become a key part of my development workflow. So when I heard about Helix, I was quite skeptical. After using it as my primary editor for the last 3 weeks, I now have a good sense for it’s strengths and weaknesses. To my surprise, I think I’m going to make the switch long-term. In this post, I’ll explain why that makes sense for me and why it might for you.

What is Helix?

Helix, like vim, is a command-line-based modal text editor. A “modal” editor means that you have different modes and each key on your keyboard does something different depending on what mode you’re currently in. You start out in “normal” mode and you go between other modes (e.g. “insert” mode to write text).

With vim, when you wish to delete the next word, you type dw for “delete word” in normal mode. In Helix, this is reversed: you type wd for “select the next word and delete”. This difference might feel odd to a vim user, but there’s a nice benefit: you see the selection you are about to operate on before you take action. In vim, you don’t have that sort of feedback on what’s going to happen until you actually commit the action.

This post isn’t going to cover all the differences in editing (here’s a great article for that).

One thing that struck me was that, despite being a fairly new editor, Helix is quite stable and has a surprising level of polish. It’s written in rust, so it’s got a big advantage over vim in speed and memory safety.

Batteries included

When you install vim, it doesn’t include any plugins and is pretty barebones. It’s very extensible, but you need to bring your own plugin manager and suite of plugins to really make it shine. There is a lot of power in this model: you can deeply customize your experience. The drawback is that, whenever the editor makes a breaking change, your plugins become out of date and you need to troubleshoot / adjust them.

Helix takes a different approach to this by including some key features and not supporting plugins. Treesitter, LSP, multiple cursors, git gutters, and auto-completion are built in to the editor. If I upgrade Helix, I know that my LSP is going to work (something I always struggle with in vim). That stability is really refreshing after years of fixing plugin compatibility issues in vim.

Config not code

Another killer feature for me is the lack of scripting support. In vim you customize your editor with vimscript (or lua in neovim). This is how you tweak settings and add new functionality. The tradeoff is the same as the previous point: flexibility at the cost of stability. Everyone’s vimscript / lua configuration is different which makes finding solutions to problems quite challenging.

In Helix, there is no scripting language. If you wish to customize your editor, you write a .toml file, which is configuration. It’s not code. As someone who is constantly tweaking my configuration, I appreciate that this saves me from myself.

There’s also much better defaults. To illustrate my point, here’s my entire configuration:

theme = "tokyonight"

[editor]
mouse = false

[editor.cursor-shape]
insert = "bar"

[keys.insert]
j = { k = "normal_mode" }

Not perfect, but better

Helix isn’t without it’s flaws, but the tradeoff of stability and simplicity is worth it to me. Some of the features I still miss are:

• The ability to toggle spell check
• File-tree explorer
• Insert-mode completion (like vim’s <C-x><C-l>)

These aren’t deal-breakers for me and, in many situations, there are pretty suitable work-arounds. I think I’m going to continue to use this editor as my daily driver for the foreseeable future.

Author’s note: I switched back to vim. It’s ubiquity (and my deeply engrained muscle memory) were enough to pull me back in. That said, I’ve simplified my configuration and am planning on “freezing” it for a few months.