That depends on the plugins selection I guess. When I tried SpaceVim its start-up time was higher than VSCode so I uninstalled it..

I have a pretty vanilla spacevim setup and it takes ages (sometimes more than 10 seconds) to start up on a very modern m1pro or recent i7. Not really sure why.

There are timing tools which let you see which plugins are causing that. That happened to me twice with Spacevim and both times it was fixed by removing a single plugin or a single line in the config related to an update to a plugin.

These configs have their pros and cons.

I have some vim users in my friend circle, and some switched because they were tired of maintaining their own configs.

However, many who tried these config vim projects spent weeks hunting down performance issues. Some switched back.

Whoever says "it's more stable because it's open source and someone else will track down the issues for you" is just too optimistic and never had any actual issues they had to debug.

Finding an issue in your "home grown" config is thousand times easier as you know your dependencies and you know what they solved. What is easier, finding an issue in a couple of hundred lines of your own code, or finding an issue in thousands of lines of someone else's configs?

As someone who tried to use Spacevim for a year+ I will say that a) it makes it more stable in a way, instead of your own hyper-custom config that could still break on updating vim/plugins you have a hundred plus other people having the same issues to debug it + a big community finding best of class Vim plugins doing the work of iterating it for you, but b) it's a bit rigid and even with the ability to tweak them you're better off either fully committing or not doing it at all because you'll be caught in between their complex config and your own breaking changes which is the worse of both worlds (as a starting config it's still very useful though).

This is ideal for people who can't be bothered to invest the time in a very personalized set up (like Linux desktop VS MacOS) but still want something more powerful and widely accessible than VSCode for most languages (the big exception being VSCode for Typescript/JS, as a Vim obsessed dev I've finally conceded to Code, since that's my day job).

> the big exception being VSCode for Typescript/JS

Why? As a neovim user with a lot of ts/js at $job, curious what if I'm missing especially useful (outside of the proprietary live-remote-session stuff)

Almost entirely because I develop Vue 3 w/ Vite on top of Rails 7 (plus a very opinionated Eslint + Prettier set up) so cutting edge plugin support = key, combined with a team that uses a mix of Vim and other stuff. VSCode's community will always completely dominate Vim for Typescript support and it's far easier to establish VSCode as the standard editor than a mix of custom Vim configs.

Even the base Vue VSCode plugin + native TS engine doesn't support my needs for modern Vue 3 <script setup /> syntax without a ton of false positive redline errors. When I switched to using Volar my life became way easier (Neovims LSP plugins are usually a year behind the VSCode native ones let alone plugins):

https://marketplace.visualstudio.com/items?itemName=Vue.vsco...

Otherwise our Ruby backend devs can use what they want. So can frontend but they'll be constantly fighting the current.

You're assuming I have a hyper-customized vim setup. Which I absolutely don't, I thought it was implied from my question that I am the opposite. I try to keep my setup as vanilla as possible because the main reason I enjoy vim is its reliability.

And of course when I say reliability, I don't just mean from crashing. I mean from unnecessary work maintaining plugins and their infrastructure.

In that case it would 100% make it less stable. I respect the vanilla Vim folks but I could never do that.

Just curious, do you also keep bash/zsh vanilla as possible? I hate sshing into servers without my rc, which is a downside. But I also don't do much sysadmin stuff so it's not a very common issue.

I use bash, and yes it's pretty vanilla. I have a custom PS1 line with some added info but no colors, no multiple lines like a lot of people do.

I've been using Linux (or Unix) for 25 years and it works well for me. I can work in large projects with many files and directories. I never even heard of people automatically transferring their RC files to remote servers. That sounds quite convenient to be fair.

That's cool. I'll always respect the diehards who value their longer term priorities over short term benefit.

Vim is a tool for editing text, and plugins exist to make manipulating text easier or make it easier to write code. I use vim over other editors because of its editing paradigms. I extend vim because I want to make my life easier. Emulation of vim in other editors is often fine to excellent, but it does make the ergonomics of using and extending the editor a little bit more complicated. Most Emacs modes need to have extensions specifically written for Evil so that things don't step on each others toes, vim's plugins are all written with that already in mind. It then becomes a matter of plugins not fighting with each other for keybindings, though that isn't really that much of an issue for me.

Given this is how I use vim, it doesn't detract from the purpose of vim for me. I'm not entirely sure what you think the point of vim is? Do you use it as your primary editor and just choose to eschew plugins for the sake of stability or do you only use it for quick edits?

In my experience of using LunarVim (which is also a preconfigured neovim). It is incredibly unstable. Plugins often don't work well with each other. Keybindings overlap. You do it with the hope of having fewer things to configure but what ends up happening is you create more config to disable slow default plugins, or add workarounds to existing ones. Updating neovim or lunarvim always breaks my config. These things aren't the least bit backward compatible.

I'm slowly switching to helix, and this time around will be forcing myself to use the defaults, and not adding a single line of config.

From my personal experience, most of the issues I encountered happened with new neovim releases and not with plugin interopability.

My config never broken because of a plugin.

The purpose of Vim for me isn't to be stable, it's to help me edit text in a very efficient manner. Lots of great plugins improve this for me.