I have been using vim for 15 years. I disagree with the idea that it makes me more efficient than someone else. First, because I have friends who don't use vim and are very fast. Second because most of my time as a developer is not spent writing/editing text.
No, I love vim because of its ergonomics. If I use a mouse for too long, my arm/shoulder starts hurting. Maybe I could improve the ergonomics of my mouse (having a vertical mouse already helped), but using vim and a tiling window manager allow me to drastically reduce my use of the mouse. It makes me more efficient than me when I use a less ergonomic setup, sure. But that's me.
It's all about ergonomics, and everyone is different. It's okay to be faster with a mouse or on an iPad.
I use vim to avoid the mouse-keyboard back and forth. I also happen to edit multiple types of file, which I find useful to have / learn only 1 editor/IDE.
I am also often, if not always, in a terminal.
Some people use vim to brag, some say it's for speed, for me it's because "it's there".
Do you modify your keyboard layout at all? I’ve tried Vim several times and many of the motions just feel awkward as hell for my fingers, but I’m on a standard wasd keyboard.
One thing I really appreciate about Vim is that it just opens. And I don't mean speed, I mean not getting bunch of pop-ups nagging me to do something about a configuration, extension, feedback or whatever.
I'm not going to claim Vim's defaults are usable for most people, but my god can these IDEs just shut up and let me see my code? I'll go to the settings if I want to.
> can these IDEs just shut up and let me see my code?
May I interest you in some Emacs? It’s arguably much more of an IDE than Vim, but it still “just opens”. And you can bring your muscle memory with you thanks to the Evil mode.
I’m not a fan of motion-action. Most of the time in vi, all I’m doing is moving around. When you input a motion key in vi it moves you accordingly with no fanfare.
The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting.
I think this stems from a fundamental misunderstanding of the vi paradigm: the primary purpose of vi was to extend the traditional line-editor ed (which was designed for editing through a paper TTY terminal) to full-screen interactive editing on a video terminal. Since early video terminals had very low baud rates, vi needed to be very efficient at reducing screen redraw. It just so happens that this emphasis is perfectly matched to the most common editing loop: jump to a location within the file and insert/delete/replace some characters. Thus vi happens to be perfectly optimized for this editing workflow and so I believe this is the reason for its enduring popularity.
The other task which vi is strong at (but which is otherwise secondary) is editing in the large: making multiple changes to a file simultaneously. This, I believe, is the primary strength of motion-action paradigm editors. In other words, they get it backwards! Thus they can’t help but annoy me while I’m working with their constant attempts to infer large-scale edits from my simple desire to jump around the file and make small changes. They are giving me a freight train when all I want is a car.
I've been experimenting with Helix in the last month.
One thing that's slightly frustrating is the key binds are running interference in my brain with the vim keybinds. Especially the x/d swap. It might be because I still use vim keybindings in other programs, but I find I'm now also worse at vim than I was before I started helix.
The discoverability is definitely a big nice feature, I definitely use more e.g. tree-sitter motions because I can actually remember them unlike in my plugins in nvim.
I found Helix much easier to get into than vim because you can see and experiment with the selection before committing to an action. It's also much more familiar to users of modern software (where you generally first select an object and then apply an action).
My problem with the "action motion" keybindings is textobjects that by necessity becomes more complex or even missing. This is a big step backwards in ny opinion.
There are also plugins that shows a pop-with with available keybindings if you want.
Yes, it’s super handy to be able to record an Emacs macro and modify large text within seconds, something that would take me half an hour. Yes, it’s super cool to navigate text at lightning speed.
But honestly, I have seen engineers who work with the mouse to navigate, and use nano to edit text in the terminal, and IDEs from intelliJ to navigate their codebase, engineers who were 10x as productive as I was. Why? Because in the end navigating your text is not what determines engineering success. It’s convenient, yes, but that’s not the core challenge. These days devs using VS Code can be magnitudes more productive just because they focus on the things that matter.
Edit:
Don’t get me wrong. I love my (mechanical) keyboard. I hardly use the mouse. I have a shortcut for everything using Keyboard Maestro, Karabiner elements, and I use Emacs for text editing, and all of that makes me super fast using my computer. But all of that does not make you a better engineer (I am not an engineer anyway). So spending time on other qualities (being able to do research, to solve problems, to manage knowledge, to communicate well, to document well) is way more relevant for your success as an engineer.
Yes people who talk about vim being more efficient, are in my opinion, misguided. For me it's very little to do with efficiency, and much more to do with creating a more pleasant experience writing text, especially text with an exploitable structure (code).
I really enjoy precision, and that's what vim provides. It's the same reason I'd much rather play an FPS video game with a mouse and keyboard, than an analog control stick. And the same reason I hate doing anything important on a touch screen.
Vim is not about speed. It’s about efficiency (less effort) and programmability. You can do the same or more editing actions with other tools, but with Vim (and also Emacs), you can make it effortless.
Vim is great. Several years ago I noticed the lack of books focused on the development experience, e.g. how to build an IDE-like experience in the era of language servers, and wrote a book about it[1]
A sad thing is that many people still believe that Vim is something mosty outdated and it’s hard to make it as useful as VS Code. But in fact it’s pretty much the opposite. I also think that the infamous steep curve is not so steep in reality.
I think an important part of the Vim workflow that I haven't seen mentioned is the fact that -at least for myself- it keeps the mind engaged during "menial" operations.
When switching from dealing with the information included in the text (typically thinking about code content) to operations of moving text around and other text logistics, I often find my mind "waiting" impatiently for my hands when using non-vim editors. In contrary, when using vim (I consider myself a mid-range user), I can somewhat remain closer to the flow.
At the same time, I still remember (albeit vaguely) a significant overhead of the Vim language before becoming acclimated.
I don't understand why people say there is an overhead. Press 'I' for insert mode gives you the same behavior as non-vim, so your immediately at the same efficiency. What am I missing?
Ditto, I switched to vim after horrible pain from eMacs’s required multi finger contortions and it helped to the point rsi hasn’t been an issue for me for 20 years.
This is such a big pro imo. Gone are those days when my hands/wrists used to be in pain from all the typing. Vim removed all that pain and made me look forward to typing as a fun activity. God bless Bram.
I wonder if learning Vim is similar to learning a musical instrument - where the real benefit isn't just speed, but the way it changes how you think about text editing?
Yesterday, I used vim motions to clean up some JMH benchmark log data to a CSV. It was genuinely so useful to be able to precisely delete and replace based on regexes. I'm sure I could have done with a graphical find and replace, but it was definitely faster via vim, especially after recording macros to automate the repetitive edits.
I am actually trying to make a site that allows users to learn vim commands by trying to beat a bot! It’s currently half baked at the moment but live at:
I tried vim motions as a daily driver many times but, I don't think that with today's expansive IDEs vim motions are all that superior. IDEs have very competent shortcuts and features built in.
My biggest problems with vim are lack of feature discoverability and the fact that you can't change the keybindings.
It's very hard to learn new things in Vim without specifically googling for them. It's highly likely that if I sat down to some online course I could learn a lot more about the Vim way of editing but I could never sit through one long enough to discover new things, so most of the things I learn about Vim come from me specifically looking up how to do certain things, not a bad way to learn, but I feel like I never got extremely proficient becasue I didn't go deep enough.
I find a lot of the keybinding to be unintuitive or not very ergonomic or inconsistent, but I also don't want to rebind anything because part of the reason vim is so useful is the fact that you get this tool with every linux install and changing things means you're no longer using The Vim. On the contrary it feels perfectly fine to tweak your IDE's keybindings because that IDE is already very specific to your needs.
I don't think anyone claims vim motions are superior in absolutes with a straight face.
I like a nearby comment that essentially says "it's not superior for everyone, it's just infinitely better for me; also it doesn't magically make anyone 100x better than the next developer".
I've seen people using IDEs and flying around massive codebases at incredible speeds, all the while they're completely mystified by even the simplest vim editing.
Me? Put me in front of an IDE and painfully witness the absolute grind: I'm a sitting duck; but in Vim I feel like my brain is plugged straight into the computer: I don't even think about my hands, code is conjured just by thinking about it.
Yes, vim is not intuitive. It doesn’t teach itself to you. It takes hard work. I bought the O’Reilly vi/vim book [1] and read it cover to cover. I practiced a lot of things and was very deliberate about it.
To me, learning vim is like learning a musical instrument. You’re not going to get there without committing to it. For many people that’s just not going to happen: they have neither the time nor the inclination/energy to do it. That’s totally fine! There are loads of other tools for people to use and they get by just fine without vim!
I think my main complaint is that there aren’t a few more tools like vim. Almost all software is designed for people to be able to pick up casually and be able to get work done at a passable level of productivity without ever reaching mastery and flow state. Tools like that (easy to use but with no real incentive for mastery) are deeply unsatisfying to me for a lot of reasons.
I guess what I’m saying here is really just a restatement of “Worse is better” [2].
I mostly like Vim because it is available everywhere and in the terminal. In its default configuration it isn't the most powerful IDE, but it is vastly more powerful that any other default experience in any other text editor (IMO). It also makes it trivially easy to shell out to external tools for modifying the text, so even for a set up that isn't heavily riced you can still do a ton.
Even when I'm forced to use another IDE for work, I try to find Vim keybindings ASAP. I like that I can learn Vim motions and actions once and use them in nearly every IDE.
I use vim & vim bindings for most editors I have (VS Code, Obsidian) and I think there's one thing always missed in this conversation (at least on HN): The changes that happens in your thinking when you start using a tool. Instead we get stuck on pros/cons of tool A vs tool B.
I got in to vim in college for two reasons (the real) one was just that I wanted to look cool, and the second one was to relive my hands of discomfort. It was also around the same time I started to look in to QWERTY vs Colemak vs Dvorak, although I didn't go further with that, I quickly realized that the keyboard layout of my country (Sweden), while similar to US/UK QWERTY placed brackets in absolute garbage positions that caused strain in my right hand a lot. Then also the excessive pressing of left/right arrow + moving right hand between mouse & keyboard caused further strain.
Vim alleviated that with the word/Word/sentence navigation being more spread out, and "stick to home-row" philosophy.
But there was an additional "shift of thinking": editor as a (limited) programming language. Being able to store macros, navigate depending not just on line/character but chunks such as word & sentences made me realize I could do things such as:
"In this XML/URDF file, replace all elements with the name=X with the logic Y, which might including adding/removing xml elements/attribute"
without having to use some scripting (python + parsing etc). The process of figuring that out is also interactive. Try out a bunch of commands, stitch them together as "macros" and then make macros that calls macros that use copy-paste registry.
If I stuck with Sublime, or VS Code, I don't think I would've had that epiphany. It even helped me (non-CS guy) to understand programming better.
Helix and Kakoune motions seem to make more intuitive sense to me, but it's unfortunate that editor support in VSCode and Zed is quite poor. I am waiting on adopting Helix as my terminal editor until the motions become more universal.
I also try LunarVim and quite liked it, but for some reason the motions didn't click, perhaps it is just a matter of practice..
Well vim comes from a different age, but it is still completely viable today.
Because you can have a GUI and a mouse today does not mean that you should not use the vim bindings. I use vim a lot in terminal (both locally or over SSH), but I also use vim bindings in graphical IDEs. Actually, I struggle if the editor doesn't have vim bindings. VScode, IntelliJ, even Xcode has vim bindings.
Funny enough, I believe that there are quite a lot of tutorials and that itself is the issue. Everyone wants to make their own since they deem the others to be bad and then a new subpar tutorial is created, making it even more difficult to find the few helpful articles. This ends up becoming a vicious cycle.
In the end I find comparing vim to something like snowboarding or skateboarding intriguing. It doesn't matter how much you explain it, it won't be enough. You just have to try it out for yourself and see if you can get the hang of it. Once that initial step is done, that's when reading about all the intricacies becomes useful.
Even if you bounce off of Vim or modern implementations like Nvim, it's worth learning the bindings. Once you get used to them, you will never go back.
The dudes in the https://ytch.xyz Programming channel display their vim editors with all kind of plugins that make me jealous. Pure fireworks. There is a plugin feature that enhances the line number where your cursor is located in the leftmost column for line numbers and looks super cool. I wish I knew the name of that plugin/feature since I don't want to go into the trial an error.
I also use the vim plugin for Eclipse and MS Code in my Linux boxes.
Yet, when the shit hits fan ... its vim-console time baby!
[+] [-] palata|10 months ago|reply
No, I love vim because of its ergonomics. If I use a mouse for too long, my arm/shoulder starts hurting. Maybe I could improve the ergonomics of my mouse (having a vertical mouse already helped), but using vim and a tiling window manager allow me to drastically reduce my use of the mouse. It makes me more efficient than me when I use a less ergonomic setup, sure. But that's me.
It's all about ergonomics, and everyone is different. It's okay to be faster with a mouse or on an iPad.
[+] [-] BrouteMinou|10 months ago|reply
I am also often, if not always, in a terminal.
Some people use vim to brag, some say it's for speed, for me it's because "it's there".
[+] [-] danielvaughn|10 months ago|reply
[+] [-] gcarvalho|10 months ago|reply
I'm not going to claim Vim's defaults are usable for most people, but my god can these IDEs just shut up and let me see my code? I'll go to the settings if I want to.
[+] [-] PhilipRoman|10 months ago|reply
[+] [-] volemo|10 months ago|reply
May I interest you in some Emacs? It’s arguably much more of an IDE than Vim, but it still “just opens”. And you can bring your muscle memory with you thanks to the Evil mode.
[+] [-] rgoulter|10 months ago|reply
Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support.
Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive.
Helix also has neat discoverability.. with pop-ups showing you what the available keybindings are.
[+] [-] chongli|10 months ago|reply
The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting.
I think this stems from a fundamental misunderstanding of the vi paradigm: the primary purpose of vi was to extend the traditional line-editor ed (which was designed for editing through a paper TTY terminal) to full-screen interactive editing on a video terminal. Since early video terminals had very low baud rates, vi needed to be very efficient at reducing screen redraw. It just so happens that this emphasis is perfectly matched to the most common editing loop: jump to a location within the file and insert/delete/replace some characters. Thus vi happens to be perfectly optimized for this editing workflow and so I believe this is the reason for its enduring popularity.
The other task which vi is strong at (but which is otherwise secondary) is editing in the large: making multiple changes to a file simultaneously. This, I believe, is the primary strength of motion-action paradigm editors. In other words, they get it backwards! Thus they can’t help but annoy me while I’m working with their constant attempts to infer large-scale edits from my simple desire to jump around the file and make small changes. They are giving me a freight train when all I want is a car.
[+] [-] drekipus|10 months ago|reply
I love helix because it is very fast, it supports everything it needs to, and the built-in help/which key. It's what I wish vim was.
Shameless self-promotion of a discussion thread I started.
https://github.com/helix-editor/helix/discussions/13399
[+] [-] Macha|10 months ago|reply
One thing that's slightly frustrating is the key binds are running interference in my brain with the vim keybinds. Especially the x/d swap. It might be because I still use vim keybindings in other programs, but I find I'm now also worse at vim than I was before I started helix.
The discoverability is definitely a big nice feature, I definitely use more e.g. tree-sitter motions because I can actually remember them unlike in my plugins in nvim.
[+] [-] klauserc|10 months ago|reply
[+] [-] lawn|10 months ago|reply
There are also plugins that shows a pop-with with available keybindings if you want.
[+] [-] inatreecrown2|10 months ago|reply
[+] [-] submeta|10 months ago|reply
But honestly, I have seen engineers who work with the mouse to navigate, and use nano to edit text in the terminal, and IDEs from intelliJ to navigate their codebase, engineers who were 10x as productive as I was. Why? Because in the end navigating your text is not what determines engineering success. It’s convenient, yes, but that’s not the core challenge. These days devs using VS Code can be magnitudes more productive just because they focus on the things that matter.
Edit:
Don’t get me wrong. I love my (mechanical) keyboard. I hardly use the mouse. I have a shortcut for everything using Keyboard Maestro, Karabiner elements, and I use Emacs for text editing, and all of that makes me super fast using my computer. But all of that does not make you a better engineer (I am not an engineer anyway). So spending time on other qualities (being able to do research, to solve problems, to manage knowledge, to communicate well, to document well) is way more relevant for your success as an engineer.
[+] [-] bspammer|10 months ago|reply
I really enjoy precision, and that's what vim provides. It's the same reason I'd much rather play an FPS video game with a mouse and keyboard, than an analog control stick. And the same reason I hate doing anything important on a touch screen.
[+] [-] lawn|10 months ago|reply
That's true, but it's still very helpful.
I'd argue that programming isn't the core challenge either, but it would be foolish to dismiss it entirely.
[+] [-] skydhash|10 months ago|reply
[+] [-] yanis_t|10 months ago|reply
A sad thing is that many people still believe that Vim is something mosty outdated and it’s hard to make it as useful as VS Code. But in fact it’s pretty much the opposite. I also think that the infamous steep curve is not so steep in reality.
[1] https://yanis-t.gumroad.com/l/vim4devs
[+] [-] bcrack|10 months ago|reply
When switching from dealing with the information included in the text (typically thinking about code content) to operations of moving text around and other text logistics, I often find my mind "waiting" impatiently for my hands when using non-vim editors. In contrary, when using vim (I consider myself a mid-range user), I can somewhat remain closer to the flow.
At the same time, I still remember (albeit vaguely) a significant overhead of the Vim language before becoming acclimated.
[+] [-] lukasstoecklein|10 months ago|reply
[+] [-] JSR_FDED|10 months ago|reply
[+] [-] loloquwowndueo|10 months ago|reply
[+] [-] rochak|10 months ago|reply
[+] [-] 404NotBoring|10 months ago|reply
[+] [-] seafoamteal|10 months ago|reply
[+] [-] Kichererbsen|10 months ago|reply
Except: Yesterday, I used an LLM (4o-mini-high) to do this kind of task instead and i might never go back.
[+] [-] nickandbro|10 months ago|reply
https://vimgolf.ai
Feel free to give it a try. Might motivate me to finish it!
[+] [-] SaintRomuald|10 months ago|reply
My biggest problems with vim are lack of feature discoverability and the fact that you can't change the keybindings. It's very hard to learn new things in Vim without specifically googling for them. It's highly likely that if I sat down to some online course I could learn a lot more about the Vim way of editing but I could never sit through one long enough to discover new things, so most of the things I learn about Vim come from me specifically looking up how to do certain things, not a bad way to learn, but I feel like I never got extremely proficient becasue I didn't go deep enough.
I find a lot of the keybinding to be unintuitive or not very ergonomic or inconsistent, but I also don't want to rebind anything because part of the reason vim is so useful is the fact that you get this tool with every linux install and changing things means you're no longer using The Vim. On the contrary it feels perfectly fine to tweak your IDE's keybindings because that IDE is already very specific to your needs.
[+] [-] lloeki|10 months ago|reply
I like a nearby comment that essentially says "it's not superior for everyone, it's just infinitely better for me; also it doesn't magically make anyone 100x better than the next developer".
I've seen people using IDEs and flying around massive codebases at incredible speeds, all the while they're completely mystified by even the simplest vim editing.
Me? Put me in front of an IDE and painfully witness the absolute grind: I'm a sitting duck; but in Vim I feel like my brain is plugged straight into the computer: I don't even think about my hands, code is conjured just by thinking about it.
[+] [-] chongli|10 months ago|reply
To me, learning vim is like learning a musical instrument. You’re not going to get there without committing to it. For many people that’s just not going to happen: they have neither the time nor the inclination/energy to do it. That’s totally fine! There are loads of other tools for people to use and they get by just fine without vim!
I think my main complaint is that there aren’t a few more tools like vim. Almost all software is designed for people to be able to pick up casually and be able to get work done at a passable level of productivity without ever reaching mastery and flow state. Tools like that (easy to use but with no real incentive for mastery) are deeply unsatisfying to me for a lot of reasons.
I guess what I’m saying here is really just a restatement of “Worse is better” [2].
[1] https://www.oreilly.com/library/view/learning-the-vi/1565924...
[2] https://en.wikipedia.org/wiki/Worse_is_better
[+] [-] jerrygenser|10 months ago|reply
[+] [-] eestrada|10 months ago|reply
Even when I'm forced to use another IDE for work, I try to find Vim keybindings ASAP. I like that I can learn Vim motions and actions once and use them in nearly every IDE.
[+] [-] NalNezumi|10 months ago|reply
I got in to vim in college for two reasons (the real) one was just that I wanted to look cool, and the second one was to relive my hands of discomfort. It was also around the same time I started to look in to QWERTY vs Colemak vs Dvorak, although I didn't go further with that, I quickly realized that the keyboard layout of my country (Sweden), while similar to US/UK QWERTY placed brackets in absolute garbage positions that caused strain in my right hand a lot. Then also the excessive pressing of left/right arrow + moving right hand between mouse & keyboard caused further strain.
Vim alleviated that with the word/Word/sentence navigation being more spread out, and "stick to home-row" philosophy.
But there was an additional "shift of thinking": editor as a (limited) programming language. Being able to store macros, navigate depending not just on line/character but chunks such as word & sentences made me realize I could do things such as:
"In this XML/URDF file, replace all elements with the name=X with the logic Y, which might including adding/removing xml elements/attribute"
without having to use some scripting (python + parsing etc). The process of figuring that out is also interactive. Try out a bunch of commands, stitch them together as "macros" and then make macros that calls macros that use copy-paste registry.
If I stuck with Sublime, or VS Code, I don't think I would've had that epiphany. It even helped me (non-CS guy) to understand programming better.
[+] [-] Perizors|10 months ago|reply
[+] [-] outlore|10 months ago|reply
I also try LunarVim and quite liked it, but for some reason the motions didn't click, perhaps it is just a matter of practice..
[+] [-] Perizors|10 months ago|reply
[+] [-] myaccountonhn|10 months ago|reply
[+] [-] pandemic_region|10 months ago|reply
[+] [-] lkuty|10 months ago|reply
[+] [-] tdiff|10 months ago|reply
Yearly(!) emergence of new tutorials trying to finally explain how to navigate with vim is a consequence of this disconnect.
[+] [-] palata|10 months ago|reply
Because you can have a GUI and a mouse today does not mean that you should not use the vim bindings. I use vim a lot in terminal (both locally or over SSH), but I also use vim bindings in graphical IDEs. Actually, I struggle if the editor doesn't have vim bindings. VScode, IntelliJ, even Xcode has vim bindings.
[+] [-] ablob|10 months ago|reply
In the end I find comparing vim to something like snowboarding or skateboarding intriguing. It doesn't matter how much you explain it, it won't be enough. You just have to try it out for yourself and see if you can get the hang of it. Once that initial step is done, that's when reading about all the intricacies becomes useful.
[+] [-] lordleft|10 months ago|reply
[+] [-] windowliker|10 months ago|reply
[+] [-] javier_e06|10 months ago|reply
I also use the vim plugin for Eclipse and MS Code in my Linux boxes.
Yet, when the shit hits fan ... its vim-console time baby!
[+] [-] pandemic_region|10 months ago|reply
You mean