Live data from Hacker News

How VSCode made bracket pair colorization faster (2021)

code.visualstudio.com

111–120 of 247 posts

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

#111
post #86
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…

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 perspective of developing features, and one I see constantly in market-brain types: the comparison is not on competing offerings but on whether the feature is present or not.

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

#112

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.

Also, Figma.

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

#113

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…

VSCode was essentially unusable for me on large projects. We're talking thousands of source files and god knows how many node_modules entries. Things like Go to Definition would regularly take 15+ seconds! Switched to WebStorm recently and have been very happy with the performance.

VS Code has stopped opening for me for certain codebases. And to be honest, these codebases aren't even that large.

I also have 0 extensions installed :(

VS Code used to be my quick and dirty IDE when I didn't want to open something heavier, but it's gotten so much more painful than even a couple of years ago.

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

#114
post #86
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…

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

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

#115
post #80

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

Yeah this sounds like a misconfiguration. We've already forgotten that native apps tend to require a bit more fine control on how they use resources, all in the name of the cult of portability.

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

#116
post #86
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…

Comparing with Xcode is a joke.

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

#117
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…

> not familiar with how incredibly fast desktop applications used to be decades ago

I have very clear memories of desktop applications from decades ago, and how incredibly fast they were, and it's "not at all", because they were slow as heck.

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

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

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

#119

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.

Even though it is based on web tech and Electron, VSCode cares about performance, while garbage like Microsoft Teams does not. That's about it.

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

#120
post #17
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.

It's not the fastest IDE out there, but it's certainly not unbearably slow.

That really depends. I used it on the same machine and it was fine enough on linux and completely unusable on windows. Same extensions, same project.

That was a few years ago now and I've since moved away due to its performance issues, though ironically I then found myself switching again to Emacs which is definitely slower than VSC

Post reply on HN