5 ms·

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

by bilalq 3y ago

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.

paulddraper 3y ago
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
- geodel 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
        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.
- deleted 3y ago
  [deleted]
- hwbehrens 3y ago
  To those who are missing it, the parent comment ^ is using sarcasm.
  - paulddraper 3y ago
    Yeah :/
  - mypalmike 3y ago
    "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.
- leidenfrost 3y ago
  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 3y ago
    It's barely alpha, but lapce is kinda trying to be a native version of vscode. https://github.com/lapce/lapce https://github.com/lapce/lapce
  - eyelidlessness 3y ago
    > 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/ https://nova.app/
- EMM_386 3y ago
  > 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.
tetha 3y ago
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 3y ago
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 3y ago
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.
- SketchySeaBeast 3y ago
  > 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.
- bilalq 3y ago
  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 3y ago
    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 3y ago
    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.
voz_ 3y ago
Comparing with Xcode is a joke.
- KnobbleMcKnees 3y ago
  Point stands about bashing electron for not being native, even if Xcode is a dumpster fire.
- wiseowise 3y ago
  Is Xcode native app?
wongarsu 3y ago
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.
- pcthrowaway 3y ago
  Sublime Code isn't an IDE
  - drcongo 3y ago
    "Sublime Code" isn't a thing at all.
  - faangsticle 3y ago
    By that measure neither is vscode. Both are extensible text editors with ide plugins available.
    - pcthrowaway 3y ago
      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
- ElectricalUnion 3y ago
  > 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.
specialist 3y ago
Yes and: Make it work, then make it correct, then finally make it fast.

by bilalq 3y ago

paulddraper 3y ago

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

geodel 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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.
deleted 3y ago
[deleted]
hwbehrens 3y ago
To those who are missing it, the parent comment ^ is using sarcasm.
- paulddraper 3y ago
  Yeah :/
- mypalmike 3y ago
  "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.
leidenfrost 3y ago
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 3y ago
  It's barely alpha, but lapce is kinda trying to be a native version of vscode. https://github.com/lapce/lapce https://github.com/lapce/lapce
- eyelidlessness 3y ago
  > 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/ https://nova.app/
EMM_386 3y ago
> 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.

tetha 3y ago

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 3y ago

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 3y ago

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.

SketchySeaBeast 3y ago
> 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.
bilalq 3y ago
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 3y ago
  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 3y ago
  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.

voz_ 3y ago

Comparing with Xcode is a joke.

KnobbleMcKnees 3y ago
Point stands about bashing electron for not being native, even if Xcode is a dumpster fire.
wiseowise 3y ago
Is Xcode native app?

wongarsu 3y ago

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.

pcthrowaway 3y ago
Sublime Code isn't an IDE
- drcongo 3y ago
  "Sublime Code" isn't a thing at all.
- faangsticle 3y ago
  By that measure neither is vscode. Both are extensible text editors with ide plugins available.
  - pcthrowaway 3y ago
    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
ElectricalUnion 3y ago
> 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.

specialist 3y ago

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