Hacker News Reader

Comment by robenkleene | Hacker News Reader

VSCode is many times slower than most non-Electron apps, e.g., in the below examples it's 9 and 14 times slower:

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).

View on HN

I think what the poster you replied to may have been referring to is that the marginal cost once the editor is open is roughly zero. If VS Code is being used, a user can hit Ctrl/Cmd-N and have a new empty text field in no time. Similarly, opening a text file is so quick that I can't perceive any passing of time between clicking on it in the file tree and seeing the file open. Perhaps users with slower computers have a different experience?

The second example I posted, illustrating that VSCode is 14 times slower than BBEdit, was opening a file with VSCode already open (it's not obvious, but VSCode was already open in both recordings, so this difference has nothing to do with its launch time).

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.

Often VS Code literally takes longer to process a single key input than Vim takes to start, load all plugins and open a session with multiple files on my machine.

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.

Can’t speak for everyone, but 1,2 aren’t operations that I do hundreds of times a day even remotely. Otoh, I can see the difference^ in scrolling highlighted text between my 6600 and 8700 boxes in vim (which is my main tool; tried and ditched vscode for many reasons but speed, which is fine at both boxes). Maybe I could see that if I looked for it, but it’s not of any import.

^ 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.

> On editors in general: I’d like to have an editor as a library for which I could create modes/cli/behaviors myself.

this is what emacs is and what makes everything else feel so poor by contrast.

> I’d like to have an editor as a library for which I could create modes/cli/behaviors myself

I think 4coder[1] might be close to what you want. It's been popularized by being used in the HandMade Hero streams.

[1] https://4coder.itch.io/4coder

I’m looking for jumping to definitions, etc. In a dynamic language. ruby.

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 has supported jump to definition via `ctags` for decades, works great for Ruby. Here's a tutorial from ThoughtBot (https://thoughtbot.com/upcase/videos/intelligent-navigation-...).

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.

Eats memory, too... Eight Gigabytes And Constantly Swapping!

Reply on news.ycombinator.com