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

221–230 of 247 posts

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

#221

Post by bemusedthrow75 »

xigoi wrote: post #175
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…

They probably have a powerful computer for $10k and don't understand that many people don't.

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.

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

#222

Post by akamoonknight »

cubefox wrote: post #207
akamoonknight wrote: post #178

Earlier quoted context omitted.

In just basic Vim, there's highlighting such that if the cursor is over a start bracket (or end bracket), the opposite bracket is highlighted. I do find that very helpful indeed to find matching brackets (or where a bracket is missing), but I can't quite see why I'd need to have the colorization as well. Essentially I guess I can see colorization as 'highlighting' multiple brackets at once. Any way you could convince…

I recently switched from an old VScode version, which has only the click dependent matching, to the new version which has it with color highlighting. The difference is that you can match brackets pretty much immediately by glancing at them. It's convenient because it is quicker.

Gotchagotcha, so yeah, to some extent eliminates the time taken to highlight individual brackets at the cost of adding some visual complexity. Thanks.

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

#223

Post by drcongo »

pcthrowaway wrote: post #155
wongarsu wrote: post #129

Earlier quoted context omitted.

Compared to Sublime Text VSCode is sluggish and hilariously bad at handling large files. Compared to Android Studio, VSCode is lean and very fast. In my opinion it's in a comfortable "fast enough" position, and from the very beginning the VSCode team has shown a great dedication to having the best possible performance in the particular technology stack they have chosen. It's just equally true that they have chosen a…

Sublime Code isn't an IDE

"Sublime Code" isn't a thing at all.

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

#224

Post by mtizim »

yCombLinks wrote: post #141
NovemberWhiskey wrote: post #131

Earlier quoted context omitted.

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

I don't think he is intentionally dishonest. When I read "decades ago", I thought "three or more", roughly the same way "several" works.

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

#225

Post by deepspace »

KeplerBoy wrote: post #18
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.

VSC feels outright snappy compared to regular Visual Studio or Eclipse. Of course one can easily bog down VSC with a bunch of bad plugins, but i really can't complain.

Yes, Visual Studio is unbearably slow for me, even with tiny projects, whereas VSC seems snappy, even with larger projects.

I also use CLion, and it is quite slow for a few minutes after startup (though never as slow as VS), but then becomes fast as it finishes indexing or something.

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

#226

Post by deepspace »

AnIdiotOnTheNet wrote: post #118
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.

To be fair, non-electron full-fat Visual Studio is also a pig.

Calling it a pig is an understatement. It is unbearably slow. I have no idea how they managed to make a native app so slow.

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

#227

Post by tetha »

bilalq wrote: post #86
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 disagree with all points here. The speed performance became possible by being able to implement this within VSCode's core rather than over the extensions API. Without proving the value proposition as an extension first, it'd be difficult to get a change like this merged into core at the start. Also, VSCode is by far the fastest IDE I've ever used. I occasionally need to interact with IntelliJ, Android Studio, and X…

Yeah, I'm a bit put off by the comments there.

Like, yeah. Neovim is faster and smaller than VSCode, by a lot on smaller hardware. And I'm pretty sure I could summon my experiences from 5 years ago or so of really putting effort into my vim setup to have many of the goodies of a modern IDE, like LSP support, search, highlighting and so forth. But sorry, if I do that, I'd have to spend like 8 hours to integrate a new language based on past experiences. Instead of just dumping an extension into a new derived profile in vscode and be done with it. And then we think about teammates who aren't as fluent in vim. Even if my Neovim/Vim setup might be faster or lower input latency at times, it won't give me that day of initial integration back, ever.

And honestly, if I think about slow editors, I think about old Eclipse builds. Maybe with bad plugins, bad Maven versions, or horribly customized to some embedded or enterprise or academic use case. Bonus points if used on shitty corporate hardware. That's a level of slow called "Looking up documentation in a browser ends up being faster than auto complete". Compared to those molochs, VScode is not slow at all if you look out a bit for plugin overload.

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

#228

Post by IceSentry »

reaperducer wrote: post #68
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.

VSCode is a good tool, but it’s unbearably slow The funny thing is that the reason I and many other people switched to VSCode is that it used to be so speedy. I sometimes wonder how much of its decrease in speed over the last few years is due to feature bloat (which it seems to have in spades) and relying on hobbyists, who have less incentive to optimize, to fill out the plug-in ecosystem. I moved my personal project…

If vscode slowed down for you it might mean you installed too many extensions.

Personally it feels just as fast or faster than before. Especially with things like the mentioned bracket colorizer beinf built in compared to the extension I was previously using.

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

#229

Post by rusl1 »

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.

Guys you should buy yourself a good MacBook because VSCode is damn good and fast on MacBooks

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

#230

Post by eyelidlessness »

leidenfrost wrote: post #152
paulddraper wrote: post #114

Earlier quoted context omitted.

You don't understand. Electron = slow and big install Even if other tools are objectively slower and bloatier, it is a immutable law that Electron = slow and big install

Even if that's true, there should be a reason, or a cause at least, that VSCode dominated over most IDEs out there. In my experience, other IDEs have either a really high learning curve, needless bloat, or are closer to a notepad with extra features rather than a full fledged developing environment. You can open VSCode and be welcomed by a lot of development features right on your face and wander through a lot of rec…

> Meanwhile, everyone is absolutely free to create a native VSCode clone. But that isn't happening at least for now.

I think Nova[1] is generally angling for that spot on Mac. I really wanted to embrace it, and someday if I have a bunch of free time to indulge my curiosity I may well do. But…

> Everyone hates VSCode, but nobody ever has managed to offer a competing alternative.

This, plus even trying a new editor that isn’t a ~direct copy of a successful incumbent is a huge investment in time, energy, and delay/diversion of muscle memory.

I resisted VSCode for years, and skipped several others entirely, because I could half ass most of what I cared about with TextMate and the other tools I had at hand. When I finally caved on VSC, reconfiguring it and myself to be maximally productive took an enormous effort.

I’m getting old and I have shit to do. I’ll do it maybe one more time in my life, but only if something comes along with a new-value proposition on the order of what VSC brought me:

- actual semantic language awareness, which works everywhere

- incredibly flexible and accurate reference navigation, again everywhere

- commit history where I’m working, whenever I need it

- debugging that’s almost seamless with editing, regardless of what’s being debugged

- I hardly even care about extensibility because most of what I need is built in, but when I do need to look for an extension it’s almost always exactly what I want (doesn’t break flow, does well what it says on the tin, doesn’t come with a kitchen sink unless it’s supposed to)

- everything I’ve missed from previous editor preferences either has a built in config equivalent or a perfectly cromulent alternative

- bonus points to VSC team beyond these criteria: 9/10 times I install an update, some new feature addresses a problem I didn’t even know I could put in words

Maybe another round of that is possible, but I’m not holding my breath.

1: https://nova.app/

Post reply on HN