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

151–160 of 247 posts

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

#151

Post by hwbehrens »

paulddraper wrote: post #114
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…

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

To those who are missing it, the parent comment ^ is using sarcasm.

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

#152

Post by leidenfrost »

paulddraper wrote: post #114
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…

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 recommended add ons that add extra value out of the box. Also, since is electron based, multiplatform support is a no brainer.

Meanwhile, everyone is absolutely free to create a native VSCode clone. But that isn't happening at least for now. Maybe UI toolkits are a mess, maybe trying to mimic an UI in a 2D library is a PITA, maybe it's that an extensions engine needs to implement some "easier to develop" language (like javascript or Lua) and a full fledged interpreter for it, and it's so much work one would rather stick with Electron and be done with it.

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

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

#153

Post by AnIdiotOnTheNet »

ramraj07 wrote: post #16
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 irony is here by far so many devs don’t mind the speed?

A statement like this just makes me think most developers are the passengers in that episode of futurama where the brains take over and make everyone stupid.

"I'm sending in more trains!" [0]

Only the trains are additional layers of abstraction and the accompanying bloat.

[0] https://www.youtube.com/watch?v=-hyttagGsz0

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

#154

Post by yoyohello13 »

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.

Yeah, I find the 'every symbol has a color' highlighting to be difficult to parse.

When everything is colorful, nothing stands out.

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

#155

Post by pcthrowaway »

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…

Sublime Code isn't an IDE

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

#157

Post by pcthrowaway »

CharlesW wrote: post #112
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.

Also, Figma.

Obsidian also

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

#158

Post by frogstomp19 »

JohnFen wrote: post #139
geodel wrote: post #125

Earlier quoted context omitted.

I think people are needlessly disparaging this beautiful, fast, lightweight tool. These look similar to haters who claimed horse cart can't be faster than automobile once some performance optimizations are put in place.

I have literally never seen an Electron-based application that wasn't overly bloated and slow to start up. I have seen a tiny number that performed decently once running, but they are the exceptions.

We're discussing one right now. VSCode is an electron-based application, isn't overly-bloated, and starts up quickly. I switch between IJ and VSC every day and VSC is significantly faster, including startup. But, even if it _was_ slower on startup, that would be a tradeoff I'd be happy with if it was faster or more functional normally. I restart my computer maybe once a week, I'd be fine to wait another couple seconds.
Post reply on HN