Stating the obvious - the edit modes are fundamentally different and helix doesn't have a plugin ecosystem yet.
Helix uses the kakoune model:
vi basic grammar is verb followed by object; it’s nice because it matches well with the order we use in English, "delete word". On the other hand, it does not match well with the nature of what we express: There is only a handful of verbs in text editing (delete, yank, paste, insert… ), and they don’t compose, contrarily to objects which can be arbitrarily complex, and difficult to express. That means that errors are not handled well. If you express your object wrongly with a delete verb, the wrong text will get deleted, you will need to undo, and try again.
Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.
This is a great point, although of course vim does let you visually select before verbing a chunk of text. Useful for cases where your object spec doesn't fit into the easy categories of character/word/block/etc.
I'm not familiar with the Kakoune or Helix selection UX, but it's keystroke-economical in vim (of course).
As I recall from trying this out a while back, it’s different mainly in being less powerful and flexible. In [n]vim you can combine these selections with all the vim grammar, including, essentially, its text objects.
Note: I used nvim daily before using helix, but only used the basic features and used lunarvim as my config.
I started using helix a few months ago because of the batteries included zero config language server setup, i have one line in my config and that is the theme, thats it, just install the language server [1] and you are ready to go.
But I stayed for the kakoune model. Yes, it is different than vim, yes it may not be for you, but to me it feels so much superior, i feel way more productive with the kakoune way. I guess i had the advantage of not having vim keybindings (except the most basic) in my muscle memory. I never really got warm with the more "advanced" vim keybindings. But in helix it is so easy to learn them. You either have a popup that shows you the next available key and what it does or you have `Space + ?` Where you can fuzzy find commands and their corresponding keyboard shortcut. Helix took that huge learning curve I had with (n)vim and turned it into learning by doing and their little tutor at the beginning.
With nvim I used lunarvim config, as I didn't want to roll my own config and it was the best I could find, and I tried all the most popular configs. They always updated something, they often broke, they felt bloated (compared to helix or plain [n]vim) and most importantely I didn't really know whats happening under the hood. With helix I only need to update my languageservers (which get automatically updated by my system package manager) and there was no need for me to touch the config files except setting the theme to one of the themes that it shipped with and I have more the feeling that I know whats happening under the hood.
Except a file tree instead of a fuzzy file picker I don't miss anything, I don't have any need for plugins, as everything I personally need is already in there.
Helix takes (IMO) the very smart approach of making language server plugins "just work". The defaults are good enough for most use cases. This is a key friction point for new users of vim/neovim that don't want to spend days setting up an IDE like experience, and something vscode and helix get right.
It lacks a good config and plugin story though, so if you're not happy with the defaults its not great.
I also just dislike the different actions. Having everything be a selection just doesn't make sense to me compared to the vim style.
Helix uses the kakoune model:
vi basic grammar is verb followed by object; it’s nice because it matches well with the order we use in English, "delete word". On the other hand, it does not match well with the nature of what we express: There is only a handful of verbs in text editing (delete, yank, paste, insert… ), and they don’t compose, contrarily to objects which can be arbitrarily complex, and difficult to express. That means that errors are not handled well. If you express your object wrongly with a delete verb, the wrong text will get deleted, you will need to undo, and try again.
Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.
Source: https://kakoune.org/why-kakoune/why-kakoune.html