The craziest thing to me is the people who are conditioned into believing that it's not slow. I don't know if it's some sort of perverse Stockholm syndrome, or if young developers today are just not familiar with how incredibly fast desktop applications used to be decades ago. I regularly have to completely reboot it because it becomes so unbearably slow, input latency alone often reaches hundreds of milliseconds. And this is on a workstation that I use to render extremely sophisticated 3D animations.
I’ve no idea what you’re on about, and I come from CLI editors (vim.) VSCode is not slow at all for me, no latency I can readily see. My only complaint is that LiveShare is incredibly buggy and my team does a ton of pair programming.
I think that's part of the issue that polarizes people: it's not consistently slow and it's not consistently fast. So you get people who can't understand how it's usable, and others who can't understand how anyone has a problem with it.
Some other editors are consistently fast, for everyone, always (like [n]vim). Not because they're special but editing text just isn't that big a deal and these editors don't try to do too much graphically, so their performance is great.
Another problem is the combination of extensions probably has a significant impact on performance and resource usage. So person A uses it to edit JavaScript and has no problem, but person B uses it to edit Ruby and has one. It might not even be VS Code's fault, maybe an extension, but it is seen as if it's the editor since it's a whole package and the input latency is what's suffering.
Neovim isn't immune to slow plugins, it's just a smaller ecosystem and therefore has less exposure.
My two cents, I've never seen a case of "VSC is slow" that isn't user error in this vein or on codebases that don't struggle similarly with similar tools. Ex, if clangd is struggling with your million file codebase under VSC it doesn't somehow become more responsive under Neovim.
And ya, anecdotally, I've never seen input latency specifically move an inch. The VSC team lives and dies on input latency and it shows in the current product.
So if I don't find it to be slow, I am not just wrong but delusional?
VSCode with the Remote SSH mode has absolutely, objectively, sped up everything I do. It's easier to work on remote machines as if they were local, it hasn't ever seemed keystroke-slow (either on a 2015 Macbook Pro or a recent Core i3 thing -- a Surface Go 2 running Ubuntu).
It has made it feasible for me to use integrated Git support in a remote environment, it has made remote file searches actually useful, it's worthwhile to make use of language servers (even for PHP!), and it presents substantially the same UI wherever I work.
It is not noticeably interactively slow.
But if it was slightly slower than, say, TextMate or SublimeText, the cost of that interactive slowness would likely be more than offset by the sheer productive utility of the thing, and no longer needing to treat host, local VM and remote VM environments differently.
It is in sum enormously faster than anything else I've used.
But this is just the deranged ramblings of a kidnap victim?
I switch between Visual Studio, Xcode and VSCode pretty much each day for C/C++ development, and out of those VSCode is by far the slickest to use (and also the most flexible). I'm also not exactly a newbie, having started to code in the mid-80s. I also tried out all the IntelliJ IDEs, and for those I cannot understand how people can put up with the UI sluggishness :)
Also: even Vim (which I often use for quick text editing tasks on the terminal) can get embarrassingly slow on large files if you start installing extensions.
Just curious - are you running some kind of debugger or profiling software through VSCode?
Because VSCode is very fast to me, and I experience literally no input latency at all. And I have used Electron based code editors that felt slow to me. Like, Atom always felt very slow to me.
This isn't a vehement defense of Microsoft or VSCode - I wish the industry had consolidated on something else, but it's the way things are right now. You don't have to use it, there are plenty of alternatives.
> I don't know if it's some sort of perverse Stockholm syndrome, or if young developers today are just not familiar with how incredibly fast desktop applications used to be decades ago.
Most of them have no idea how fast a computer is because they've been using ludicrously slow software for so long they just think that's normal. Microsoft developers these days seems to have a particularly warped understanding of what "fast" means in computing, see Teams startup times [0], VS startup times [1], or that whole debacle with Windows Terminal.
[1] I couldn't find a video in a reasonable time frame, but it is very slow compared to its predecessors just to launch let alone do anything that might justify it.
> not familiar with how incredibly fast desktop applications used to be decades ago
I have very clear memories of desktop applications from decades ago, and how incredibly fast they were, and it's "not at all", because they were slow as heck.
I know it's electron and a resource hog, meanwhile I virtually never need to reboot it and it never lags for me and I can't recall it crashing on me. Maybe I don't type fast enough to notice some of the laggy behavior but that's how I'm conditioned to believe it's just fine for me and I run it on a MB Air. I've used several IDE's over the years and feel like if I had something performance-wise to complain about I would have noticed it by now.
>how incredibly fast desktop applications used to be decades ago.
... that'd be during the time period when WordStar 5.0 would have to load an overlay from the floppy drive (taking a few seconds at least) in order to, e.g. print, and the speed of spell checking was such that you could actually follow along as the checker scanned through your document?
Decades ago also occurred decades after that. The average desktop app in 2003 felt faster than the average desktop app in 2023. The fact that you chose an app from 1983 shows you're intentionally dishonest.
It's all about tradeoffs. I like the features I get from VSCode and find its ergonomics outweigh other editors enough that I choose it over them, even if it may not be as fast. Am I conditioned or stupid?
(I rarely have to restart it because input has lagged to hundreds of ms. Maybe if that happened regularly to me, I would feel the same as you.)
I think performance complaints about vscode are either from bad extensions/too many OR poor system resources.
When I first started my current job, they gave me a laptop that was under specced due to the high performance laptops being back ordered.
Vscode performed really poorly, but so did everything else. MS teams was the worst offender by far. I had to close every other application in order to join a meeting, lol
Who knew that having 100% CPU and 100% ram usage would slow applications down...
I've never ever run it on a $10K computer. It's quick enough on a Surface Go 2 (albeit in Linux, not on Windows). It's quick enough on an eight year old 2.7ghz i5 MacBook Pro. And it's even not shockingly awful on an 8GB Raspberry Pi 4B.
