Ask HN: Is switching from VSCode to Vim worth it?
I used the vim extension for about a month and am now making what is a very jarring/uncomfortable switch to exclusively using vim (neovim technically). I thought I had comfortably got the movements inside a file down, but now that I’m trying to navigate medium/large projects, I see how much more I need to learn before I can “break even” and get back to my speed/comfort in vscode. I’m finding myself doubting the amount of time I’m dedicating to configuring/practicing vim and am seeking insights as to whether or not this is a worthwhile way to spend my time as I don’t really know what the vim endgame looks like, while vscode was definitely good enough.
41 comments
[ 3.2 ms ] story [ 86.8 ms ] threadVim shines when you need the same editing interface anywhere, on any VM, any server, any machine.
If that's not you and VSCode suits your needs, especially around navigating large projects, then I'd say stick with that.
I don't know what your EC2 experiences have been like, of course, but there are ways to increase the reach of VS Code even into your EC2 instances. On the one side, are you editing a lot of dotfiles that should maybe be in a git repo and synced anyway? On the other side, maybe something like VS Code's very cool SSH remoting tools are more what you need: https://code.visualstudio.com/docs/remote/ssh
Form thin pc I preffer to use Zed code editor from google apps, this small js program works offline and do not freeze for large code base.
For terminals i prefer micro, it is golang written code editor.
Recently dev.github.com provides online code editor that works with ci/cd piplines.
'if it ain't broke, don't fix it' - if you find that you are able to work comfortably with vscode with the vim extension, and it is meeting all your needs, then honestly that might be what works best for you. However, if you find that you are hitting walls with extensibility or flexibility, _then_ it's time to maybe consider a switch. in my experience of using vim for like a decade now, a successful vim user is often someone who is _obsessed_ with squeezing usability and optimization out of their tools/toolchain. I have seen many an engineer try and force Vim on themselves because of the perception they think others will have of them as a somehow more skilled or 'in the know' engineer. And while i'm not suggesting thats what you are doing, it's definitely a pattern i've seen more and more.
Moral of the story, figure out what you need out of your tools and adapt your toolchain to those needs. and if navigation is your main issue, you should look into easy-motion and Tags, those will help a lot.
And for what it's worth. After a lot of tinkering and thinking about my own goals, i ultimately settled on Doom Emacs, and that's been my preferred editor for a few years now. Many vimmers have found that to be the ideal 'endgame', anecdotally, at least.
I could care less about what people think of the editor I use. The ergonomic benefit is nice, but after seeing a video[0] of someone who is clearly years ahead in vim fluency, I am so drawn to the idea of having my productivity limited by my thoughts vs how quick I can interaction with my editor.
[0] https://youtu.be/-I1b8BINyEw
in my experience the best way to can the fluency you are seeking is to delete vscode, or put it somewhere that you can't see on your machine. when you have a thing that ''''works'''' and you are trying to learn a new thing, it can be an anti-pattern to have such easy access to the thing you are trying to stop using. for example, when i switched to dvorak, i was most successful when i forced myself to only use dvorak, no qwerty, no exceptions. it slowed me down for a week or two, but necessity got me to where i needed to go. the same holds true for vim, that was the same approach i took. even if it means i'm slower for a little bit while i figure out motions, configurations, etc, it got me to where i am now, which is a place where i can do my job in vim (or in my case, evil(vim) mode in emacs) much faster than i could in any editor.
best of luck!
As for mouse-reaching, just flip it over (maybe put a sticky note over laptop trackpads). If you touch it, think, hey, there's probably a way to do this without the mouse. For vim usage, I would also say the same thing about arrow keys (especially in insert mode). Disable these training wheels & see your productivity skyrocket.
Im trying to move completely to Lunarvim, a vim config with a lot of neat tools built in, but only because I fell in love with the keybinds and I don't want to spend the time configuring vscode or pycharm to do the same. That said, I still swap to pycharm or vscode for the debugger.
Otherwise I use non-GUI Emacs. Before that I used vim. My biggest motivation for using terminal-based text editors is that they're faster than GUI editors and easier to switch between CLI tools and the editor. Also, I prefer to do my development within remote servers (that are much beefier than my laptops/desktops). So I just SSH in and do the work.
I'm ok with giving up the builtin niceties like jump-to-definition and syntax-aware find-replace. (I could get this working in emacs but it never works in every language or I forget how to set it up when switching environments or something so I end up not using this kind of feature).
If you have a motivation then you'll figure out how to make it work eventually. If you don't have these kinds of motivations then I'm not sure why you'd pick terminal editor.
However, it's not a skill developed overnight. It takes time to invest in the tool, but for me the payoff has been significantly increased productivity. I won't ever stop learning new vim skills though. It's both wide and deep. Vim just makes sense to me now, but it took a while to really get it.
I eventually decided to try out Emacs, and settled on Spacemacs, which comes with Evil mode pre-installed (a Vim emulation layer on top of Emacs), so I basically had to learn some Vim bindings. Now I'm on Doom, which uses them even more heavily. And boy do I regret not having learned this stuff sooner. So much faster and simpler than jumping through UIs and pointing and clicking.
If you haven't heard of it already, Vim/NeoVim come with a tutorial built-in, called Vimtutor. Definitely run through that for a quick interactive primer on how to effectively use the basics.
Also, the bonus is that Vim is much more lightweight and snappy than VS Code, even on much older and cheaper machines. So you'll feel at home anywhere you run it. The same cannot be said for VS Code.
That's strange, most code editors have advanced keyboard shortcuts for almost everything you can do with pointing and clicking. You just have to learn the combos.
Keep in mind that even though vscode's vim extension is not bad, it has significant differences to the point it degrades the user experience and gets in the way.
But maybe they are doing something super high performance and need fast edit test cycles they can't get on their laptop, although I'm not exactly sure what kind of task needs that.
I'd recommend using one of the pre-baked configs (LunarVim, Astro, NvChad) to get a taste for what a batteries included vim build feels like. If you're like me you'll use it for a while, tinker with the configs etc. until you reach a point where something annoys you and you'll build a config from scratch. Seeing a fully completed config and playing with it has been really useful!
Was it worth it? Hard to say, but I'm now at the point where all the vim stuff is muscle memory, and I'm now getting comfortable with macros etc. You reach a point where rather than thinking of editing code as an interaction with an interface you start to think of it as just editing code. It's a difficult concept to get across but the fact i rarely interact with a mouse has definitely led me to become less easily distracted while coding.
My custom config feels like what I imagine having a model railway would feel like. It takes a bit of maintenance and tinkering, but it does exactly what i want it to and I get a sense of satisfaction from keeping it up to date.
It's difficult to describe how incredibly valuable this is. Pretty much my entire software stack[1] is scriptable, which means I can sand every corner as soon as it becomes an issue. The impact to my productivity from reduced mental load is honestly incalculable, and I'm pretty sure I couldn't concentrate nearly as deeply on complex things without it.
[1] I've started scripting my browser to behave better too, but that's the main holdout at this pt
That said when I do configure, I'm dedicated to it. The goal is to set it and forget it for literally years in order to build up muscle memory. So it's worth playing around and finding what works.
It did take me a few months of consistent use to get better in Vim than other editors. I think that's faster than most people? I'm a pretty good typist so I think that probably makes a big difference. All of which is to say:
- Definitely stick with it (maybe try to think of it as "cool" rather than a slog, maybe investigate cool plugins or color schemes to help reinforce that)
- Invest in your config
- Work on your typing (and address any discomfort that arises--super important)
If you like VSCode and feel productive in it, you should stick with it. If you're in a situation where you're able to go slower and ramp up with vim, I think that would be a good time to try it out. The end-game is that your vim-config is truly portable, and no matter where you go, you'll be able to easily duplicate your work environment. Also, once you master the motions, you'll be much faster navigating bigger code-bases and can easily work on a server if need be.
If it's not fun, then it's probably not worth it. It really depends on what VIM can do to improve your current workflow. So, you may need to drop the VSCode mindset while you start using VIM.
> but now that I’m trying to navigate medium/large projects,
I actually have trouble navigating large projects in VSCode. The buffer, tab, window model that Vim uses makes more sense to me (but it's unique to VIM afaik, so it may be jarring at first). Combine that with a fuzzy finder[1] and it allows:
- rip-grep to search for files with text / file names
- Searching through currently currently opened buffers
Whenever I have to use VSCode (mainly for the live share feature, I find myself pretty lost with VSCode's tab based interface (I usually end up with like 20 tabs cluttering my workspace, and tabs are local to a split, which is jarring for me).
> the vim endgame looks like
It never _really_ ends. Some VIM features that I miss when I use another editor are:
- Really nice integration with terminal commands. One thing that I do very often is copy the name of the current file: `!echo % | xclip -sel clip` so I can use the filename as an argument in a terminal split (running tests for example)
- Filters (`:help !`) so I can pass parts of a file in to a program that accepts standard input. Example: `'<,'>!jq` to prettify bits of JSON.
- Global commands and macros. VSCode vim supports them, but I've noticed that they can run pretty slowly.
- The buffer, tab, window, model (probably the biggest one I miss when I start using VSCode)
For LSP support, I've tried to migrate to neovim's native LSP tools, but I still find COC to be a lot more intuitive. You should feel right at home with it since a lot of the plugins are similar to their VSCode counterpart.
If you'd like a really general and guided tour of VIM, I'd recommend picking up Practial Vim[2] It really helped me understand the workflow a bit more. Approaching VIM with the mindset of another editor wont give you all the benefits of using VIM. Though, if the workflow doesn't click, then that's not a big deal. You can always go back to VSCode.
[1] https://github.com/Shougo/denite.nvim (many people use Telescope: https://github.com/nvim-telescope/telescope.nvim) [2] https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...
Yes, VSCode definitely has its own model similar to Vim's buffer/tab/window but that is somewhat unique to VSCode. There are some deep keyboard shortcuts that are similar, but quite different to Vim's, and I recall the VSCode Vim plugin tries its best to split the difference, somewhat.
Something I find very helpful with VSCode tab management in complex scenarios is the "Open Editors" pane. By default it is at the top of the Explorer panel. I think it defaults to minimized in fresh installs, though, but deep in the past it was the "only" tab management interface and a little bit more central to early VS Code workflows so some of us learned to rely on it early and others coming into VS Code fresh don't notice it at all. It's still one of the easiest places to do more complex tab and split management when the vertical tab bars are too cramped to be as useful as a horizontal list of opened tabs/splits.
[1]: https://marketplace.visualstudio.com/items?itemName=martybeg...
1. While you are working with software tools, keep an eye out for actions you repeat and/or spend quite a bit of time on.
2. Find out if there is a command (or macro facility etc.) that will do this action quicker. Read the documentation, ask a friend, or look at how others do this.
3. Train using the command. Do this until your fingers type it without thinking.
This means that you can learn new commands only as the need comes up by observing what you do. Which commands you will want to learn thus depend on the operations you are frequently doing and/or that cost you a lot of time.
As I said, that strategy is applicable in general. Tools however differ in how well they support it, e.g. in terms of available commands and facilities.
You could start applying that strategy in VSCode (which I’m not familiar with, by the way). If it works well enough, great. If you find it limiting, switch to Vim, Emacs, or some other IDE that serves your needs better.
[0] https://moolenaar.net/habits.html
[1] https://youtu.be/eX9m3g5J-XA
On the other hand, I primarily program Android at work, and in 2009 Android recommended I use the Eclipse IDE, so I learned how to use that. Then starting around 2013, Android said they were shifting from Eclipse to Android Studio, so then I learned that. Android Studio has odd keyboard shortcuts - on a Linux (or Windows) box you jump to a line by hitting Control-G - on a Mac you hit Command-L.
The vi on my Mac and Linux seem fairly similar in terms of keyboard shortcuts and what I use now on both of them is what I used in 2013 and what I used in 1989 as well, and I have used it for a host of things. Whereas even in the specialty of Android programming, the recommended IDE switched some years back, and it has differences on different platforms.
The future of vim is more vim. I have been using vi and its descendants for over 30 years, and the core behavior is the same as it has always been. It has done all I ever needed, and it works everywhere and over slow connections.
The future of VSCode is at the mercy of Microsoft, and that absolutely will change under you without warning. They control the value of the skills that you learn. Why would you take that risk?
Most of my development is in TypeScript, which has a pretty good language server, so I don't feel like I'm really missing out on any of the "IDE" features that I get in VSCode. I am not a "pure vim" zealot, so I have a decent amount of plugins to bring my environment closer to an "IDE" than "just vim" (eg. NerdTree, fugitive, surround, sneak).
I haven't really touched my dotfiles in a year or two outside a few custom keybinds for new workflows I find myself repeating.
Getting good at whatever editor you choose to use for your daily development is a good investment. If you're going to choose one, vim is probably a decent choice for how long it's stayed around.
[0] https://github.com/neoclide/coc.nvim
Also, if you use languages for which an IDE provides significant value - continue using whatever IDE you are using (... if you don't enjoy the vim/shell lifestyle). Vim is not an IDE, though it can eventually be configured to act like one. If you mainly program in C for example, an IDE provides minimal value beyond what a lightly configured Vim would provide.
Source: Near-full time vimmer and terminal tools user. I found joy in the journey as an end in and of itself.