Live data from Hacker News

How VSCode made bracket pair colorization faster (2021)

code.visualstudio.com

201–210 of 247 posts

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

#201

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…

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.

Just an anecdote for those curious about a specific experience.

This time I used VSCode for nearly 2 months. Thought it's the end of an era, I'm not coming back to Sublime Text. I decided to push through and customize the configs just right for me, it was really becoming comfortable. Main reason why I wanted to switch is more active dev, more active extension community, and well integrated modern (some ML-backed) code writing and navigation tools.

I was wrong. After all the painstaking customization to bring it close to my ideal experience, while also getting used to things I didn't want to fight, I still had a bad time.

For one, the tab/cursor focus keeps going into weird places. I press a button, like ESC to switch to normal vim mode, and instead it does nothing, or something different, because turns out I'm not in the editor anymore. Keeps happening, maybe my own fault. The nifty AI tools integration is more of a nuisance — they jump in at bad times (with a delay), and their tab/enter functionality is weird, can never get it right. Most of my autocompletes have been unintentional. Maybe my own fault again, but felt super awkward. There is still no good vertical align plugin, despite such an active community (Sublime doesn't have one either, although they have one that gets me a bit closer). The language server stuff that worked badly in Sublime for my language also works badly in VSCode. The extensions, while numerous, are of questionable quality. I tried to stick to just a few well known ones.

After all the effort, I slowly came to realization that I'm back to not really using anything unique to VSCode, sacrificing more than I gained, being surrounded by lots of small moving details everywhere in the UI that make my experience more awkward than helpful, and occasionally getting my cursor stuck in weird parts of UI. I went back to Sublime.

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

#202

Earlier quoted context omitted.

Sublime Code isn't an IDE

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

I guess I didn't realize Sublime has had LSP packages for a while now, though IIUC it still doesn't support it out of the box

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

#203

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.

People act as if their precious app is the only one a user is going to run and has the right to hog all the memory and CPU.

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

#204

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.

I think WebAssembly might play a role there. https://twitter.com/mattrickard/status/1410714002456383490

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

#205

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…

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.

Compared to the others neovim should theoretically be snappier. Could it be bogged down by 3rd party plugins or something? If so try to switch to the lazy.nvim plugin manager which does a great job of lazy loading plugins, but more importantly allows you to profile the startup time and tweak loading mechanisms until you find a desirable balance between loading plugins and startuptime.

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

#206
post #64

Earlier quoted context omitted.

It's better than other Electron programs (a low bar, since most of those perform shockingly poorly) but eats way more system resources and performs noticeably worse than Sublime Text, on my machine.

Sublime text is an editor, VS Code is an IDE, though? The featuresets aren't the same.

I'd say they compete in a similar space of smart plugin-friendly code editor, not IDE.

What are you thinking of, in terms of differences? I use both quite a bit (some of VSCode's plugins are better) and have always viewed them as very close to one another, in terms of features.

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

#207

Earlier quoted context omitted.

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…

I recently switched from an old VScode version, which has only the click dependent matching, to the new version which has it with color highlighting. The difference is that you can match brackets pretty much immediately by glancing at them. It's convenient because it is quicker.

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

#208
post #206

Earlier quoted context omitted.

Sublime text is an editor, VS Code is an IDE, though? The featuresets aren't the same.

I'd say they compete in a similar space of smart plugin-friendly code editor, not IDE. What are you thinking of, in terms of differences? I use both quite a bit (some of VSCode's plugins are better) and have always viewed them as very close to one another, in terms of features.

For one thing VS Code has a full debugger with breakpoints and stack analysis that supports many backends out of the box, that's an IDE feature.

Sublime doesn't have any (real) debugger even with plugins. Some attempt to tack on a debugger but they have to do so via popup menus or overloaded "magical" text buffers and it's atrocious. Why can't I click on the line I want to break on? Why can't I see the stack in a nice editable tree? Right, because sublime is a text editor and VS Code is an IDE.

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

#209

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

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

Yeah :/

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

#210

Earlier quoted context omitted.

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…

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

VS Code does that too and I think that's plenty to find matching brackets.

Never understood colored brackets either, it looks like a noisy rainbow to me. But I think it might depend on the language+theme combination you're using.

Post reply on HN