> 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.
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.
Also, I don't understand at all what your last sentence there means.
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.
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.
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...
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
These look similar to haters who claimed horse cart can't be faster than automobile once some performance optimizations are put in place.
I have seen a tiny number that performed decently once running, but they are the exceptions.
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.
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.
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.
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.
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.
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 project 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.
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
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.
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.
For me, Neovim has always been faster than VS Code and that was before switching to Lazy plugin manager.
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.
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.