I haven't noticed any performance issues in vim to start with. It was fast on a 75MHz pentium for me. The syntax highlighting, same. No issues. I don't always use that though because I can't be bothered to set up anything much past the basic config.

At one point vim lacked asynchronous plugins. If a plugin was running a builder or linter it locked the editor up (from what I recall).

That fell apart when people wanted vim to do some more modern IDE kind of things like all the “… on save” stuff (build on save, test, lint, etc). I think LSP support is native in neovim as well.

I believe vim merged asynchronous plugin support a while back though, so I’m not sure how different they really are anymore.

That seems like solving the wrong problem.

Just run make from another terminal...

It was a real problem, but as GP already mentioned, Vim has integrated some version of it since Vim 8 (2016), probably at least somewhat motivated by NeoVim (forked 2014).

https://lwn.net/Articles/713114/

I hadn't noticed.

IIRC vim became really slow with the combination of large source files (thousands of lines of code) and language server plugins (e.g. code completion and live error squiggles).

I had a C program that was a single file 140,000 lines long back then. No issues.

Vanilla vim sure, no problem. But try to add syntax highlighting and code completion plugins.

Ah yes, the "I've never had this problem so obviously no one else could have possibly had it" argument.

No it's more the "what the hell are people doing to make their lives difficult?" argument.

To be fair, they were just sharing their experience. I don’t recall them saying anything close to your interpretation.

I was using vim-enhanced as red hat-based distro installed it. No customization. No customization of nvim either.

I often use vim or nvim on disposable machines, so persistent undo is something very low on my list of things I want.

Tree-sitter is more performant for sure, and its potential for easier text objects is nice. However, Vim's syntax engine is more than good enough for non-complex highlighting (and many people don't want complex highlighting) and, while I don't have enough tree-sitter knowledge to explain this myself, I've seen examples of Lua versions of Vim plugins where tree-sitter is unable to handle some of the regex-based text objects present in the vimscript version.

As far as really cool uses for tree-sitter go, ast-grep is a fantastic tool. Of course it's a standalone program, so it doesn't need nvim to make use of it.