How VSCode made bracket pair colorization faster (2021) • Hacker News Board

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

#161

Post by b5n » Thu, Jun 22, 2023, 5:22 PM UTC

bilalq wrote: post #127

uoaei wrote: post #111

Earlier quoted context omitted.

In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"? Thus just seems blindingly obvious to me and probably anyone who's spent more than 40 hours writing code. > It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode One of my favorite mis-applications of opportunity cost from the perspe…

Maybe blindingly obvious in hind-sight, but none of the IDEs I mentioned in my last comment have this feature. Nor does any other IDE I've ever used. It's not hard to imagine why a novel feature, without much prior art, potentially sitting on the blocking path for UI rendering, and contributed by an external person would face friction in being merged into core. Not to mention the onboarding complexity of making a cha…

It's always entertaining to me to see 'new'(ish) IDE features being lauded that have already been available in emacs for years, if not decades.

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

#162

Post by [deleted] » Thu, Jun 22, 2023, 5:23 PM UTC

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.

[deleted]

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

#163

Post by vladvasiliu » Thu, Jun 22, 2023, 5:24 PM UTC

bilalq wrote: post #127

uoaei wrote: post #111

Earlier quoted context omitted.

In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"? Thus just seems blindingly obvious to me and probably anyone who's spent more than 40 hours writing code. > It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode One of my favorite mis-applications of opportunity cost from the perspe…

Maybe blindingly obvious in hind-sight, but none of the IDEs I mentioned in my last comment have this feature. Nor does any other IDE I've ever used. It's not hard to imagine why a novel feature, without much prior art, potentially sitting on the blocking path for UI rendering, and contributed by an external person would face friction in being merged into core. Not to mention the onboarding complexity of making a cha…

After a quick search through the settings, IntelliJ seems to indeed not have bracket colorization. I seem to remember there was an option for this, but it may have been a 3rd party plugin.

However, it has something that I find superior: when you're on a bracket, it will highlight its opposing bracket (closing if you're on opening, and vice versa).

The reason I think it's superior is that you can see directly which specific bracket you're looking for, you don't have to hunt for the corresponding shade. And in case your brackets are unbalanced, you'll see it directly.

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

#164

Post by mynameisvlad » Thu, Jun 22, 2023, 5:24 PM UTC

bluSCALE4 wrote: post #148

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.

I mean, yes? That's kind of the point of extensions; to provide additional functionality through specific APIs.

Chrome/Safari/Firefox extensions certainly don't have full access to everything the browser can do. Nor can IntelliJ plugins. Nor can... practically any other implementation of extensions.

https://github.com/microsoft/vscode is available if a developer wanted to contribute something to core, anyway.

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

#165

Post by faangsticle » Thu, Jun 22, 2023, 5:24 PM UTC

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

By that measure neither is vscode. Both are extensible text editors with ide plugins available.

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

#166

Post by jve » Thu, Jun 22, 2023, 5:27 PM UTC

uoaei wrote: post #111

bilalq wrote: post #86

Earlier quoted context omitted.

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…

In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"? Thus just seems blindingly obvious to me and probably anyone who's spent more than 40 hours writing code. > It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode One of my favorite mis-applications of opportunity cost from the perspe…

> seems blindingly obvious

Well, for me it IS helpful when the code block doesn't fit on single screen and I have to scroll AND there are multiple levels of brackets. Usually I try to put a cursor and not move it vertically and scroll to see where it ends. And coloring helps here.

Sometimes I want to understand - hey, where is the closing bracket, because there are 3 openings on single line, some expressions formatted on some lines, typecasts and whatnot that litters () around. Format document may not help there to align everything if I got any bracket missing there.

And I usually exit early, trying not to make too nested constructs, not using excess (), prefer constructs that eliminate brackets altogether. Anyways, not always we read our code. Of course python people can laugh that they don't even have such an issue, but others have, you know.

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

#167

Post by zenapollo » Thu, Jun 22, 2023, 5:28 PM UTC

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.

I’ll bet a lot of this whole argument is just windows v mac. VS code is snappy on Mac, much less so on my windows machine.

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

#168

Post by JdeBP » Thu, Jun 22, 2023, 5:34 PM UTC

I suspect that one of these days someone will just bite the bullet and write an abstract syntax tree editor, and eliminate at a stroke all of the "first, we turn the text into an abstract syntax tree" steps that occur in everything from code colourization through folding to code suggestions. (-:

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

#169

Post by IceSentry » Thu, Jun 22, 2023, 5:34 PM UTC

mrweasel wrote: post #104

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.

Why is it that VSCode is the only good Electron app? I get that Microsoft have talented developers, but so does other companies, yet VSCode remain the single application that shows that Electron apps can work.

I use discord and gitkraken every day and I've never had any issues either. People just like to complain. They act as if using a few hundred megabytes for the main app you are using is an issue. It's not the 90s anymore ram is cheap, especially at those amount.

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

#170

Post by ElectricalUnion » Thu, Jun 22, 2023, 5:39 PM UTC

wongarsu wrote: post #129

bilalq wrote: post #86

Earlier quoted context omitted.

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…

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…

> Compared to Android Studio, VSCode is lean and very fast.

It was most likely some specific detail of my previous old piss-poor Windows work computer environment but the ad-hoc, whole project + all_java_dependencies + entire_jdk full file scanning on every single file opened (no matter if it was the same file opened) by the Visual Studio Code for Java Language Service (remember, it's Windows, so under molasses slow file access/reading) made everything extremely painfully slow for me in Visual Studio Code.

Granted, JetBrains IntelliJ took 50s+ to open the project in such bad environment but it didn't constantly rescan the whole thing every time another file was opened.

Things seems to have been improving a lot (Visual Studio Code for Java Language Service Lightweight Mode and JetBrains Fleet Lightweight Mode comes to mind) since that, but it is still the reason why I use those JetBrains IDEs at all.