Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How VSCode made bracket pair colorization faster (2021)

code.visualstudio.com

Post reply on HN
Print view View original

141–150 of 247 posts

Re: How VSCode made bracket pair colorization faster (2021)

#141

Post by yCombLinks »

NovemberWhiskey wrote: post #131
Solvency wrote: post #15

Earlier quoted context omitted.

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. An…

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

Re: How VSCode made bracket pair colorization faster (2021)

#142

Post by AnIdiotOnTheNet »

Solvency wrote: post #15
voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

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. An…

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

[0] https://twitter.com/i/status/1640972391265230848

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

Re: How VSCode made bracket pair colorization faster (2021)

#143

Post by vbezhenar »

fragmede wrote: post #58
vbezhenar wrote: post #24

Earlier quoted context omitted.

That's surprising to hear, because I use vscode every day and its performance is miles away of any JS apps I've ever used. It truly feels like a native app when it comes to performance, at the same time keeping some "fluidity" of web app (like scale the entire UI with single key press or reloading the entire app like a web page). I'd say I never had issues with vscode performance and actually its performance is a maj…

What CPU do you have? Because even though VSCode is "just" a text editor, I've found it's relatively demanding. A Core 2 Duo, which is admittedly a little old, but which does absolutely fine with vim, is slow to the point of being unusable with VSCode.

Apple M1 Max.

I understand that everyone's situation is different, but I live in a poor country, making like $2k/month and still consider investments into my computer worthwhile, so I never tried to save money on it. This is american website, so most people here surely can afford fast computer for their work.

Re: How VSCode made bracket pair colorization faster (2021)

#144

Post by marginalia_nu »

akkad33 wrote: post #80
sebzim4500 wrote: post #51

Earlier quoted context omitted.

For the most part I agree with you but "miles away of any JS apps" is a low bar to cross.

I use vs code and jet brains intellij. Vscode is by miles more stable and light weight for running a java spring app. Of course intellij runs a lot of stuff but the experience is not better for it. Intellij feels like a sloth next to vscode

IntelliJ is not very fast by any benchmark. I mean it's based on Swing! There's a pronounced multi-frame pause between right clicking and seeing a context menu.

C++ based editors like Kate blow both VSC and IJ out of the water. Runs so fast it feels janky, like the computer isn't doing anything.

Re: How VSCode made bracket pair colorization faster (2021)

#146

Post by nickelpro »

dlisboa wrote: post #126
edgyquant wrote: post #32

Earlier quoted context omitted.

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…

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.

Re: How VSCode made bracket pair colorization faster (2021)

#147

Post by hinkley »

voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

I still use Jetbrains but I don’t really push it on other people the way I used to. It was always a pig, but it was less of a pig than Eclipse, which I haven’t met anyone who still uses it in a long time, so now Jetbrains is “the pig “.

I figured the targeted versions would fix that, but I haven’t found that to be the case, or at least not for mature projects.

Point is, VSCode isn’t trying to be good, it’s just trying to be better than Jetbrains. Which is a nearly universal failure mode in this industry, and why it takes us so long to get good tools. If someone throws a terrible tool out, we have to go through two or three generations of replacements before someone finally has an original idea that isn’t built on the misguided one we started with.

The bones for running other languages or enhanced Java on the JVM were laid down in Java 1.2, but the first assembler built for Java was terrible. It wasn’t even a macroassembler, you had to do your own pointer arithmetic for the stack and IIRC for the constant pool. It was two assemblers later before we got one that made me say, “this is actually pretty usable” and I don’t think it’s a coincidence that the number of JVM languages basically doubled a short time after that. We could have had all of this in 1998, not 2008.

Re: How VSCode made bracket pair colorization faster (2021)

#148

Post by bluSCALE4 »

tomcatfish wrote: post #87

Everyone saying "This isn't a speedup, this is VSCode stopping being dumb" hasn't read carefully enough: The speedup is from taking extension code built on a limited API and implementing it inside VSCode, using more information while doing so.

I read it as extension developers will never be able to match core since their api is limited.

Re: How VSCode made bracket pair colorization faster (2021)

#149

Post by RektBoy »

voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

Don't forget, NO multi-screen/window support, which is ridiculous. Apparently everybody code on 40" TV screen or something, rofl.

Re: How VSCode made bracket pair colorization faster (2021)

#150

Post by grog454 »

Solvency wrote: post #15
voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

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. An…

Some people can't tell the difference between 17 ms of latency and 68 (4 frames at 60hz), while some can't bear it.
Post reply on HN