[bilalq]

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 XCode. The difference in responsiveness is night and day. Before VSCode, I would almost exclusively just use Vim. It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode, a native IDE developed by a company with an integration advantage of being in control the underlying OS and hardware.

[wongarsu]

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 technology stack that puts easy extensibility over performance.

[misnome]

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.

[hakunin]

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.

[srik]

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.

[alwillis]

+1 for Lazy: https://github.com/folke/lazy.nvim

For me, Neovim has always been faster than VS Code and that was before switching to Lazy plugin manager.

[pcthrowaway]

Sublime Code isn't an IDE

[drcongo]

"Sublime Code" isn't a thing at all.

[faangsticle]

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

[pcthrowaway]

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

[wiseowise]

Sublime Text in no way represents “average” native application. It doesn’t even use native GUI toolkits, ffs.

[ElectricalUnion]

> 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 file access/reading) made everything extremely painfully slow for me in Visual Studio Code.

Granted, JetBrains IntelliJ took 50s+ to open the project in such bad environment but it didn't constantly rescan the whole thing every time another file was opened.

Things seems to have been improving a lot (Visual Studio Code for Java Language Service Lightweight Mode and JetBrains Fleet Lightweight Mode comes to mind) since that, but it is still the reason why I use those JetBrains IDEs at all.

[411111111111111]

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

[tetha]

Yeah, I'm a bit put off by the comments there.

Like, yeah. Neovim is faster and smaller than VSCode, by a lot on smaller hardware. And I'm pretty sure I could summon my experiences from 5 years ago or so of really putting effort into my vim setup to have many of the goodies of a modern IDE, like LSP support, search, highlighting and so forth. But sorry, if I do that, I'd have to spend like 8 hours to integrate a new language based on past experiences. Instead of just dumping an extension into a new derived profile in vscode and be done with it. And then we think about teammates who aren't as fluent in vim. Even if my Neovim/Vim setup might be faster or lower input latency at times, it won't give me that day of initial integration back, ever.

And honestly, if I think about slow editors, I think about old Eclipse builds. Maybe with bad plugins, bad Maven versions, or horribly customized to some embedded or enterprise or academic use case. Bonus points if used on shitty corporate hardware. That's a level of slow called "Looking up documentation in a browser ends up being faster than auto complete". Compared to those molochs, VScode is not slow at all if you look out a bit for plugin overload.

[gloosx]

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

[uoaei]

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.

[bilalq]

Maybe blindingly obvious in hind-sight, but none of the IDEs I mentioned in my last comment have this feature. Nor does any other IDE I've ever used. It's not hard to imagine why a novel feature, without much prior art, potentially sitting on the blocking path for UI rendering, and contributed by an external person would face friction in being merged into core. Not to mention the onboarding complexity of making a change like this in core vs as a standalone extension for a new contributor.

Also, I don't understand at all what your last sentence there means.

[b5n]

It's always entertaining to me to see 'new'(ish) IDE features being lauded that have already been available in emacs for years, if not decades.

[vladvasiliu]

After a quick search through the settings, IntelliJ seems to indeed not have bracket colorization. I seem to remember there was an option for this, but it may have been a 3rd party plugin.

However, it has something that I find superior: when you're on a bracket, it will highlight its opposing bracket (closing if you're on opening, and vice versa).

The reason I think it's superior is that you can see directly which specific bracket you're looking for, you don't have to hunt for the corresponding shade. And in case your brackets are unbalanced, you'll see it directly.

[SketchySeaBeast]

> 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"?

One where there is finite time and resources and you have to pick and choose what you tackle. I could easily see this being ignored knowing that VSCode is so extensible and the community could easily pick up the missed non-core functionality until there was time to do it right.

[jve]

> 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 formatted on some lines, typecasts and whatnot that litters () around. Format document may not help there to align everything if I got any bracket missing there.

And I usually exit early, trying not to make too nested constructs, not using excess (), prefer constructs that eliminate brackets altogether. Anyways, not always we read our code. Of course python people can laugh that they don't even have such an issue, but others have, you know.

[EMM_386]

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

[specialist]

Yes and: Make it work, then make it correct, then finally make it fast.

[voz_]

Comparing with Xcode is a joke.

[KnobbleMcKnees]

Point stands about bashing electron for not being native, even if Xcode is a dumpster fire.

[wiseowise]

Is Xcode native app?

[paulddraper]

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

[leidenfrost]

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.

[IceSentry]

It's barely alpha, but lapce is kinda trying to be a native version of vscode.

https://github.com/lapce/lapce

[eyelidlessness]

> Meanwhile, everyone is absolutely free to create a native VSCode clone. But that isn't happening at least for now.

I think Nova[1] is generally angling for that spot on Mac. I really wanted to embrace it, and someday if I have a bunch of free time to indulge my curiosity I may well do. But…

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

This, plus even trying a new editor that isn’t a ~direct copy of a successful incumbent is a huge investment in time, energy, and delay/diversion of muscle memory.

I resisted VSCode for years, and skipped several others entirely, because I could half ass most of what I cared about with TextMate and the other tools I had at hand. When I finally caved on VSC, reconfiguring it and myself to be maximally productive took an enormous effort.

I’m getting old and I have shit to do. I’ll do it maybe one more time in my life, but only if something comes along with a new-value proposition on the order of what VSC brought me:

- actual semantic language awareness, which works everywhere

- incredibly flexible and accurate reference navigation, again everywhere

- commit history where I’m working, whenever I need it

- debugging that’s almost seamless with editing, regardless of what’s being debugged

- I hardly even care about extensibility because most of what I need is built in, but when I do need to look for an extension it’s almost always exactly what I want (doesn’t break flow, does well what it says on the tin, doesn’t come with a kitchen sink unless it’s supposed to)

- everything I’ve missed from previous editor preferences either has a built in config equivalent or a perfectly cromulent alternative

- bonus points to VSC team beyond these criteria: 9/10 times I install an update, some new feature addresses a problem I didn’t even know I could put in words

Maybe another round of that is possible, but I’m not holding my breath.

1: https://nova.app/

[geodel]

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.

[JohnFen]

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.

[frogstomp19]

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.

[JohnFen]

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.

[hwbehrens]

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

[mypalmike]

"Don't be snarky" is mentioned in the first rule of hn commenting. To be fair, I don't always abide by it either, but it's a good rule.

[paulddraper]

Yeah :/

[EMM_386]

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