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

181–190 of 247 posts

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

#181

Post by troupo »

akkad33 wrote: post #80
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.

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

IntelliJ has a lot of legacy code, including custom re-implementation of all things UI.

And it offers vastly more features than VS Code.

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

#182

Post by 411111111111111 »

ElectricalUnion wrote: post #170
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…

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

The issue is that you tried to use vs code for Java. That plugin doesn't really work well, honestly.

The performance would have been pretty much the same if you used it like sublime text, so no plugins beyond synthax highlighting

And before someone claims that's not fair because sublime text has plugins too: no, it (to my knowledge) doesn't have any that enable the same classpath scanning vs code (and intellij or eclipse) does for java

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

#183

Post by JohnFen »

frogstomp19 wrote: post #158
JohnFen wrote: post #139

Earlier quoted context omitted.

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 second…

VSCode is better than many, but I do think it counts as bloated, has reasonably high recommended machine requirements, and performs more poorly than I would expect of such an application.

It does perform better than IJ and the like, but that's a bit of damning with faint praise.

I don't comment beyond that on it as I don't use it more than I have to (for reasons unrelated to it being Electron-based) and want to avoid Speaking Of That I Know Not. I was speaking about Electron more generally.

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

#184

Post by EMM_386 »

jve wrote: post #166
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…

> 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 formatte…

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

Maybe they'll port this feature to VS Code.

I tried it out, solves the problem you mentioned.

https://devblogs.microsoft.com/visualstudio/sticky-scroll-st...

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

#185

Post by troupo »

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.

> Why is it that VSCode is the only good Electron app?

Because you need to sink hundreds of thousands of man-hours into making it work.

And fight against web tech most of the time you're doing that.

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

#186

Post by EMM_386 »

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

> Electron = slow and big install

This isn't the 1990s. My username alone should show I went through a period where the size of the binary and the memory size mattered.

These days with have gigabyte/terabyte hard drives and gigabytes of RAM. It generally sits unused and the O/S will handle reallocating if you really put the pressure on.

I'm not too concerned about VS Code hitting my RAM cap. Right now, with the entire front-end of a large enterprise application loaded, it's using 350 MB of RAM.

Meaningless in the grand scheme of things. And it's fast, on a 3 year old laptop.

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

#187

Post by EMM_386 »

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.

> It's not the 90s anymore ram is cheap, especially at those amount.

I just wrote the exact same thing in another comment.

That's what the problem is ... it's the old timers complaining that things aren't native, thus they are RAM hogs and are slow by default. Even if they are fast, they are "slow and bloated" just because it's the gut reaction when you have layers on layers of other stuff over native code.

And I'm an old timer but I am not complaining. I love VS Code and I think it's blazing fast for what I need it for, a large Angular enterprise application.

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

#188

Post by misnome »

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…

I switched away from sublime text because it only had a fraction of the features and extensions. Perhaps I'm just not using files large enough, most of our source modules top out at a few thousand lines of code.

And VSCode could be much, much worse. I tried AstroNvim on neovim for a while after it got some attention here. It consistently started up slower for me than VSCode does.

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

#189

Post by theRealMe »

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.

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

There’s a word for what you are trying to explain. The word is “fix”.

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

#190

Post by TheLoafOfBread »

eikenberry wrote: post #98
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.

Software developers are conditioned to accept horribly slow interactions with their software due to compilers. Most compiled languages have zero regard for developer time with the lengthy compile times. The break in context and flow from those constant delays and the horrible hacks in tooling around trying to deal with it are a constant irritant that has taken root and just accepted.

Now imagine that you are doing a development on embedded platform - To the compilation time you will add time to load the application and time to boot it up.
Post reply on HN