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

241–247 of 247 posts

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

#241

Post by whynotminot »

5e92cb50239222b wrote: post #236
whynotminot wrote: post #199

Earlier quoted context omitted.

If I could roll my eyes any harder, they’d be spinning. 99.9% of people who complain about electron apps are not ardent defenders of third world computing. It just violates their sensibilities.

I am not one of those "99.9%" (seems like a random number pulled out of someone's ass). Most developers in my poor country don't make much and would quality as lower-middle class in yours. Including a good friend of mine, who is learning web development on a 10-year old laptop — he can't afford anything else. I know he struggles with VSC because I hear about it daily.

I feel for your friend, and I hope he gets some better hardware solutions soon.

But I think it’s unfair to hold developer tools back to 10 year old specifications.

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

#242

Post by taeric »

mynameisvlad wrote: post #164
bluSCALE4 wrote: post #148

Earlier quoted context omitted.

I read it as extension developers will never be able to match core since their api is limited.

I mean, yes? That's kind of the point of extensions; to provide additional functionality through specific APIs. Chrome/Safari/Firefox extensions certainly don't have full access to everything the browser can do. Nor can IntelliJ plugins. Nor can... practically any other implementation of extensions. https://github.com/microsoft/vscode is available if a developer wanted to contribute something to core, anyway.

Emacs stands in stark contrast to this claim, though. Some things do get moved into native code so that it can run faster, but at large most of it is implemented in the same code and paths that everyone has access to at runtime.

(For examples of "to run faster," I'm talking of json and such. Calling out to the tree-sitter library is there, too. I'm not clear why that has to be native, oddly.)

I can certainly understand and agree with browsers having more locked down sections. For expert developer tools, though, it does feel a touch weirder.

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

#243

Post by Solvency »

NovemberWhiskey wrote: post #131
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. ... that'd be during the time period when WordStar 5.0 would have to load an overlay from the floppy drive (taking a few seconds at least) in order to, e.g. print, and the speed of spell checking was such that you could actually follow along as the checker scanned through your document?

https://twitter.com/jmmv/status/1671670996921896960

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

#244

Post by Solvency »

bigbillheck wrote: post #117
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…

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

Try again. https://twitter.com/jmmv/status/1671670996921896960

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

#245

Post by akkad33 »

5e92cb50239222b wrote: post #238
akkad33 wrote: post #218

Earlier quoted context omitted.

It does everything I need to run to do my job. If intellij is doing more stuff that is slowing it down then maybe they can find a better performance-feature trade off by getting rid of the bloat

It would turn into another run of the mill text editor like VSCode then, and would lose most of its users.

Vs code is not a run of the mill editor though. It can be configured to support all useful features of intellij. Even then it's faster than intellij

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

#246

Post by ColonelPhantom »

wenc wrote: post #82
fragmede wrote: post #58

Earlier quoted context omitted.

What CPU do you have? Because even though VSCode is "just" a text editor, I've found it's relatively demanding. A Core 2 Duo, which is admittedly a little old, but which does absolutely fine with vim, is slow to the point of being unusable with VSCode.

I used to run vim and VS Code on a Core 2 Duo from 2005. Vim is a lot faster but VS Code is so much more powerful — it’s a full featured IDE. It’s not a quick and dirty text editor like Kate. It’s not meant to be that. I still use vim to edit config files but for everything else I use VS Code. I’ve since upgraded to a 2014 i7 and now VS Code feels fast.

Kate is not a "quick and dirty text editor" either? Kate has session and project support (admittedly a bit more clunky than VSCode, but it works), good LSP support, decent built-in search, GDB integration, a built-in terminal, Git integration, etc. Sure, it may be less polished than VSCode in some of these aspects, but they're there and mostly just work.

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

#247

Post by gloosx »

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…

If you used VIM, there is no possibility VSCode would feel faster in any sense, I don't understand how it is possible. You can plug in the whole VSCode tooling inside VIM making it the same in terms of functionality, and it would not affect its startup time or input lag whatsoever - it will remain unnoticeable. It is possible to open infinite copies of vim recursively inside vim's own terminal, so even if I recursively stack up 32 vims with all my plug-ins loaded inside each other, they still don't show a hint of a lag
Post reply on HN