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

171–180 of 247 posts

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

#171

Post by IceSentry »

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…

It's barely alpha, but lapce is kinda trying to be a native version of vscode.

https://github.com/lapce/lapce

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

#172

Post by xigoi »

IceSentry wrote: post #169
mrweasel wrote: post #104

Earlier quoted context omitted.

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.

Why is it better to have a million people buy more RAM, creating a large amount of electronic waste and emissions, instead of putting some effort into not unnecessarily wasting resources?

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

#173

Post by xigoi »

phpisthebest wrote: post #79
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 Are you still using that same computer from decades ago?

If the applications could be fast on that computer, why can't today's applications be fast on the same computer?

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

#175

Post by xigoi »

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…

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

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

#176

Post by tomtom1337 »

JdeBP wrote: post #168

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

That is what tree-sitter is, I think? https://tree-sitter.github.io/tree-sitter/

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

#177

Post by kortex »

Solvency wrote: post #2

And yet, somehow, no one has done anything to address the inherent issues for colorblind developers. All of these colorization add-ons are woefully inadequate in that regard.

Can't you just define the symbol color pallet in options? (I'm not a vscode user, I use JetBrains and I just define my own colors)

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

#178

Post by akamoonknight »

cubefox wrote: post #156
Narishma wrote: post #74

Do people really like this type of syntax highlighting? The screenshots in the article to me are a hard to read color soup.

It's very useful when trying to find matching brackets in code!

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 me that having this multiple identification has been preferable to the single identification?

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

#179

Post by EMM_386 »

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, 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'm on a 3+ year old laptop writing enterprise Angular on it with numerous plugins and it's very fast.

I feel like your view may be impartial due to a dislike of Electron over native applications.

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

#180

Post by specialist »

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…

Yes and: Make it work, then make it correct, then finally make it fast.
Post reply on HN