1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993
2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889
I'm just as surprised as you are that people do see it, that some people don't see it. I have no idea what the explanation is, but there's something radically different about me versus people who can tolerate VSCode's slowness (I'll use VSCode if I have to, but I'll avoid it if at all possible, just because it's slow).
There's some truth to your comment though, in that VSCode's optimizations are very on rails, i.e., if you go the slightest bit off the beaten path (like I opened a file from the Finder, instead of from the sidebar, in the BBEdit/VSCode video), then VSCode approach to optimization falls apart (you can find accounts of the tricks VSCode uses to appear fast online, there's a lot of smoke and mirrors based around specific workflows -- I think making a new tab is actually the example they use). It wouldn't surprise me if part of the reason I perceive it as so slow is I expect every feature to be fast, not just to most common ones. And I think this is a perfectly fair metric to measure by. Emacs, Vim, BBEdit, and Sublime Text are all fast at everything they do, therefore I think it's fair to call VSCode a slow editor, even if technically it's average for a couple of features.
Granted, it's not a high-end workstation, just a laptop from 2016. But I don't think it's slow; when Vim first released it could have beaten the fastest supercomputer. Now of course that's a matter of perspective, but I hope I'm not the only one who thinks editing a package.json shouldn't make any modern PC sweat.
In IntelliJ command B will take me where something is defied, be it system library or in code base. Not perfect but close.
I’ve not had luck getting vim to do this.
Vim also supports the same LSP implementations that VSCode uses via Coc.nvim (https://github.com/neoclide/coc.nvim), which provides the same code navigation features that VSCode has, including jump to definition.
^ not just slower, vim annoyingly skips scroll events if they arrive too fast. My system is configured for 6-7 lines per WM_SCROLL, and I guess that adds to the problem. As a result I have to scroll slower (at 6600 box) for vim to scroll faster.
On editors in general: I’d like to have an editor as a library for which I could create modes/cli/behaviors myself. I believe that the sharpest tool is the one you sharpened yourself and for basic editing there is notepad2 and alikes. Vscode is much closer to that, but it’s too cumbersome to create/update personal extensions, so dumb vim hacks be it.
this is what emacs is and what makes everything else feel so poor by contrast.
I think 4coder[1] might be close to what you want. It's been popularized by being used in the HandMade Hero streams.
VSCode load times are heavily correlated to what files I had open last and what extensions I have installed that trigger because of my previously opened files.
When I freshly install VSCode on a machine, it feels blazingly fast. A couple months later when I've loaded up a few linting extensions? Not so much. Of course, the power of these extensions is why I'm using VSCode in the first place. I've yet to see an IDE that can integrate these types of features and not slow-down in some aspect, and VSCode does seem to try to stay as lightweight as possible.
VScode also often has notification prompts when I open it, either from extensions, or as popups generated from the editor itself. This doesn't add load time perse, but it does add to my mental perception of it's load time.
I also literally only use VSCode when I have to work with Typescript.