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.
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.
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.
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.
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.
> 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.
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
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.
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
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
That's surprising to hear, because I use vscode every day and its performance is miles away of any JS apps I've ever used. It truly feels like a native app when it comes to performance, at the same time keeping some "fluidity" of web app (like scale the entire UI with single key press or reloading the entire app like a web page).
I'd say I never had issues with vscode performance and actually its performance is a major factor why I use it.
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.
Oh noes, who could’ve thought that application written in JavaScript that gets executed on browser engine is slower than lean C++ that uses their own custom GUI toolkit
http://news.ycombinator.com/item?id=2822114.
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.
Ah—I'd never noticed VSCode could do that, in years of using it. I ignore some of its features (some of which Sublime also has, and I tend to ignore them there, too) because I find them janky and fragile or requiring-configuration such that I lose a lot of time keeping them happy, like any kind of run-from-editor stuff and the built-in terminal (it always seems to have a messed-up environment or get itself into broken states) dropping to a separate terminal for that sort of thing. Not like when I'm, say, working in XCode or Intellij and almost exclusively run, build, & debug from inside the IDE, rarely touching a separate terminal.
Guess you've got a point, then, and I just don't use it that way.
I use vs code and jet brains intellij. Vscode is by miles more stable and light weight for running a java spring app. Of course intellij runs a lot of stuff but the experience is not better for it. Intellij feels like a sloth next to vscode
IntelliJ is not very fast by any benchmark. I mean it's based on Swing! There's a pronounced multi-frame pause between right clicking and seeing a context menu.
C++ based editors like Kate blow both VSC and IJ out of the water. Runs so fast it feels janky, like the computer isn't doing anything.
It also does maybe a quarter of what IDEA can do. Let's see how it performs when it catches up to what IDEA does right now (maybe in another ten years).
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
Yeah this sounds like a misconfiguration. We've already forgotten that native apps tend to require a bit more fine control on how they use resources, all in the name of the cult of portability.
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.
Why is it better to have a million people buy more RAM, creating a large amount of electronic waste and emissions, instead of putting some effort into not unnecessarily wasting resources?
You don't need to buy more ram. It was already cheap a decade ago. Ram has been in the multiple gigabyte range for longer than that. Having an app that you use all the time every day use a few hundred of the otherwise unused ram is perfectly reasonable.
> It's not the 90s anymore ram is cheap, especially at those amount.
I just wrote the exact same thing in another comment.
That's what the problem is ... it's the old timers complaining that things aren't native, thus they are RAM hogs and are slow by default. Even if they are fast, they are "slow and bloated" just because it's the gut reaction when you have layers on layers of other stuff over native code.
And I'm an old timer but I am not complaining. I love VS Code and I think it's blazing fast for what I need it for, a large Angular enterprise application.
Or maybe you're just fine with throwing away thousands of dollars at it every few years, so you're not seeing the problem. The "solution" that most of the world simply cannot afford.
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.
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 think unfortunately a CPU from 2008 just isn't gonna cut it here. Single thread benchmarks core for core have risen about 4x since then, average core counts have risen 4x, and L3 caches were added. Probably SIMD instructions are a consideration here as well.
That being said I'm a huge fan of prioritizing longevity of computer parts versus constantly upgrading and generating e-waste.
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.
I understand that everyone's situation is different, but I live in a poor country, making like $2k/month and still consider investments into my computer worthwhile, so I never tried to save money on it. This is american website, so most people here surely can afford fast computer for their work.
VSCode was essentially unusable for me on large projects. We're talking thousands of source files and god knows how many node_modules entries. Things like Go to Definition would regularly take 15+ seconds! Switched to WebStorm recently and have been very happy with the performance.
I've not had any issues with speed ever since i started excluding directories that contain junk stuff that you know you will not ever need to see in a project's view.
If you have large files (as in hundreds of MB or bigger) in your project directory, especially text files, it also really pays off to put them into either your .gitignore or the files.exclude.
Often happens to me when I run projects that output large CSVs, and it's a very notable performance impact.
Today I worked with not-so-large project: 255 typescript files, 26K LoC, 920 modules in node_modules, 29351 js/ts files total (with node_modules), 4.5M LoC total. I just checked and go to definition works pretty much instantly.
Anyway go to definition is a function of LSP server, AFAIU. I understand that it's bundled with vscode and feels like a single product, but still I'd separate vscode and LSP servers and judge them differently.
>We're talking thousands of source files and god knows how many node_modules entries.
I think most VSCode features are disabled for node_modules directories by default.
At a guess, I'd say re-disabling that in your workspace file would resolve all of your performance issues. For even simple projects you'd be including hundreds of MB of text files, and thousands of subdirectories.
VS Code has stopped opening for me for certain codebases. And to be honest, these codebases aren't even that large.
I also have 0 extensions installed :(
VS Code used to be my quick and dirty IDE when I didn't want to open something heavier, but it's gotten so much more painful than even a couple of years ago.
> 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.
Read carefully. The extension API limited the extension performance - so they implemented it in core. It was not a builtin feature of VSCode before. From article:
>> VS Code's API and extension architecture was not designed to allow for high performance bracket pair colorization when hundreds of thousands of bracket pairs are involved...
>> While we would have loved to just improve the performance of the extension (which certainly would have required introducing more advanced APIs, optimized for high-performance scenarios), the asynchronous communication between the renderer and the extension-host severely limits how fast bracket pair colorization can be when implemented as an extension. This limit cannot be overcome...
>> Instead, in the 1.60 update, we reimplemented the extension in the core of VS Code and brought this time down to less than a millisecond - in this particular example, that is more than 10,000 times faster...
As a rather vocal user of Sublime Text 4, VS Code is an order of magnitude slower on basic UI interaction.
I eventually switched to VS Code but I miss immediate highlighting and extremely fast start times. It's very close to TextEdit launch speeds. VS Code crawls by comparison.
The only reason I'm using VS Code is the plugin system is way better.
There is a Microsoft-built plugin called Remote - SSH, which fits into a group called "Remote Development" that includes WSL and Docker versions. It basically runs most of vscode on the remote, and feels just as fast as local on a decent connection. Most of the heavy lifting is done on the remote so things like full project searches, or linting, etc not having to go through ssh to access the files.
I use it for almost all of my development. I launch an ec2 instance with my projects and all of my code and data stays in my dev vpc. I can connect from my laptop or workstation and I can spin up extra dev environments if I am working on multiple projects. Plus, since the projects usually involve a pretty big data set, i don't have to download that locally and it can be replicated quickly within the vpc for each dev environment.
The SSH extension even knows how to forward ports back and you can add/remove port forwards from the vscode ui.
They are probably using "Remote - SSH" by the VSCode team. It was a big part of what convinced me to switch from Pycharm. That and being able to work on C++ code from the same tool.
> look, I'm sorry, but the rule is simple:
> if you made something 2x faster, you might have done something smart
> if you made something 100x faster, you definitely just stopped doing something stupid
It might be stupid, or it also might just be naive, or a shift in priorities.
100x throughput improvement might just come from caching results from earlier computations (less naive) - at the cost of 10x memory footprint possibly (different priorities).
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. And this is on a workstation that I use to render extremely sophisticated 3D animations.
I’ve no idea what you’re on about, and I come from CLI editors (vim.) VSCode is not slow at all for me, no latency I can readily see. My only complaint is that LiveShare is incredibly buggy and my team does a ton of pair programming.
I think that's part of the issue that polarizes people: it's not consistently slow and it's not consistently fast. So you get people who can't understand how it's usable, and others who can't understand how anyone has a problem with it.
Some other editors are consistently fast, for everyone, always (like [n]vim). Not because they're special but editing text just isn't that big a deal and these editors don't try to do too much graphically, so their performance is great.
Another problem is the combination of extensions probably has a significant impact on performance and resource usage. So person A uses it to edit JavaScript and has no problem, but person B uses it to edit Ruby and has one. It might not even be VS Code's fault, maybe an extension, but it is seen as if it's the editor since it's a whole package and the input latency is what's suffering.
Neovim isn't immune to slow plugins, it's just a smaller ecosystem and therefore has less exposure.
My two cents, I've never seen a case of "VSC is slow" that isn't user error in this vein or on codebases that don't struggle similarly with similar tools. Ex, if clangd is struggling with your million file codebase under VSC it doesn't somehow become more responsive under Neovim.
And ya, anecdotally, I've never seen input latency specifically move an inch. The VSC team lives and dies on input latency and it shows in the current product.
So if I don't find it to be slow, I am not just wrong but delusional?
VSCode with the Remote SSH mode has absolutely, objectively, sped up everything I do. It's easier to work on remote machines as if they were local, it hasn't ever seemed keystroke-slow (either on a 2015 Macbook Pro or a recent Core i3 thing -- a Surface Go 2 running Ubuntu).
It has made it feasible for me to use integrated Git support in a remote environment, it has made remote file searches actually useful, it's worthwhile to make use of language servers (even for PHP!), and it presents substantially the same UI wherever I work.
It is not noticeably interactively slow.
But if it was slightly slower than, say, TextMate or SublimeText, the cost of that interactive slowness would likely be more than offset by the sheer productive utility of the thing, and no longer needing to treat host, local VM and remote VM environments differently.
It is in sum enormously faster than anything else I've used.
But this is just the deranged ramblings of a kidnap victim?
I switch between Visual Studio, Xcode and VSCode pretty much each day for C/C++ development, and out of those VSCode is by far the slickest to use (and also the most flexible). I'm also not exactly a newbie, having started to code in the mid-80s. I also tried out all the IntelliJ IDEs, and for those I cannot understand how people can put up with the UI sluggishness :)
Also: even Vim (which I often use for quick text editing tasks on the terminal) can get embarrassingly slow on large files if you start installing extensions.
Just curious - are you running some kind of debugger or profiling software through VSCode?
Because VSCode is very fast to me, and I experience literally no input latency at all. And I have used Electron based code editors that felt slow to me. Like, Atom always felt very slow to me.
This isn't a vehement defense of Microsoft or VSCode - I wish the industry had consolidated on something else, but it's the way things are right now. You don't have to use it, there are plenty of alternatives.
> 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.
Most of them have no idea how fast a computer is because they've been using ludicrously slow software for so long they just think that's normal. Microsoft developers these days seems to have a particularly warped understanding of what "fast" means in computing, see Teams startup times [0], VS startup times [1], or that whole debacle with Windows Terminal.
[1] I couldn't find a video in a reasonable time frame, but it is very slow compared to its predecessors just to launch let alone do anything that might justify it.
> 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.
I know it's electron and a resource hog, meanwhile I virtually never need to reboot it and it never lags for me and I can't recall it crashing on me. Maybe I don't type fast enough to notice some of the laggy behavior but that's how I'm conditioned to believe it's just fine for me and I run it on a MB Air. I've used several IDE's over the years and feel like if I had something performance-wise to complain about I would have noticed it by now.
>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?
Decades ago also occurred decades after that. The average desktop app in 2003 felt faster than the average desktop app in 2023. The fact that you chose an app from 1983 shows you're intentionally dishonest.
It's all about tradeoffs. I like the features I get from VSCode and find its ergonomics outweigh other editors enough that I choose it over them, even if it may not be as fast. Am I conditioned or stupid?
(I rarely have to restart it because input has lagged to hundreds of ms. Maybe if that happened regularly to me, I would feel the same as you.)
I think performance complaints about vscode are either from bad extensions/too many OR poor system resources.
When I first started my current job, they gave me a laptop that was under specced due to the high performance laptops being back ordered.
Vscode performed really poorly, but so did everything else. MS teams was the worst offender by far. I had to close every other application in order to join a meeting, lol
Who knew that having 100% CPU and 100% ram usage would slow applications down...
I've never ever run it on a $10K computer. It's quick enough on a Surface Go 2 (albeit in Linux, not on Windows). It's quick enough on an eight year old 2.7ghz i5 MacBook Pro. And it's even not shockingly awful on an 8GB Raspberry Pi 4B.
The slowness that I've observed almost always comes from the language servers. The rest really isn't much worse, if at all, than something like emacs.
I do keep looking for lighter options, but have yet to find one that actually does all the things I want. Vim and emacs are okay, but getting the right plugins to get the right features I want is a pain. Other options seem to lack the ability to add those features at all.
Language servers are slow. Nobody could have predicted this since on paper json for process to process communication seems like a very sound choice, if the geniuses at microsoft could not solve such a difficult problem then surely this was the best option out of all the potential bad ones.
I still use Jetbrains but I don’t really push it on other people the way I used to. It was always a pig, but it was less of a pig than Eclipse, which I haven’t met anyone who still uses it in a long time, so now Jetbrains is “the pig “.
I figured the targeted versions would fix that, but I haven’t found that to be the case, or at least not for mature projects.
Point is, VSCode isn’t trying to be good, it’s just trying to be better than Jetbrains. Which is a nearly universal failure mode in this industry, and why it takes us so long to get good tools. If someone throws a terrible tool out, we have to go through two or three generations of replacements before someone finally has an original idea that isn’t built on the misguided one we started with.
The bones for running other languages or enhanced Java on the JVM were laid down in Java 1.2, but the first assembler built for Java was terrible. It wasn’t even a macroassembler, you had to do your own pointer arithmetic for the stack and IIRC for the constant pool. It was two assemblers later before we got one that made me say, “this is actually pretty usable” and I don’t think it’s a coincidence that the number of JVM languages basically doubled a short time after that. We could have had all of this in 1998, not 2008.
VSC feels outright snappy compared to regular Visual Studio or Eclipse. Of course one can easily bog down VSC with a bunch of bad plugins, but i really can't complain.
Yes, Visual Studio is unbearably slow for me, even with tiny projects, whereas VSC seems snappy, even with larger projects.
I also use CLion, and it is quite slow for a few minutes after startup (though never as slow as VS), but then becomes fast as it finishes indexing or something.
You're overlooking the fact that the reason that VSCode is good is precisely that electron enables a high development velocity.
Edit: also, if you read the article, you'll find that the 10k x performance increase is a comparison between the performance of a third-party extension and the performance once that extension has been rewritten and inlined into VSCode itself. It's not like they were being accidentally quadratic or something.
I switched from Pycharm to VSCode because on my 2015 MBP, Pycharm was too sluggish. (Mostly a memory hog, I think.) Now that I'm on an M1 Max, vscode feels completely unconstrained, and I suspect Pycharm would as well.
Though, to be fair, I did actually run into an actual "borderline-frozen" situation yesterday doing a regex search that matched a bunch of very long lines in a log file.
The reason wasn't JS performance or Electron, but simply that bracket colorization was bolted on in an extension which had to make use of the existing extension API, which obviously didn't expose the needed internal features to properly implement bracket colorization.
The exact same thing would have happened in a native editor if its plugin interface didn't anticipate a particular requirement.
Software developers are conditioned to accept horribly slow interactions with their software due to compilers. Most compiled languages have zero regard for developer time with the lengthy compile times. The break in context and flow from those constant delays and the horrible hacks in tooling around trying to deal with it are a constant irritant that has taken root and just accepted.
Now imagine that you are doing a development on embedded platform - To the compilation time you will add time to load the application and time to boot it up.
> 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'm on a 3+ year old laptop writing enterprise Angular on it with numerous plugins and it's very fast.
I feel like your view may be impartial due to a dislike of Electron over native applications.
Well, sometimes to make things 10k x faster you need to implement some really complex algorithms. Implementing a trivial solution doesn't mean that it was broken or wrong in the first place.
Imagine saying "machine learning" was broken because now it's 10k x faster to train using a dedicated TPU than a CPU, so we should have used TPUs from the start.
A statement like this just makes me think most developers are the passengers in that episode of futurama where the brains take over and make everyone stupid.
"I'm sending in more trains!" [0]
Only the trains are additional layers of abstraction and the accompanying bloat.
The funny thing is that the reason I and many other people switched to VSCode is that it used to be so speedy.
I sometimes wonder how much of its decrease in speed over the last few years is due to feature bloat (which it seems to have in spades) and relying on hobbyists, who have less incentive to optimize, to fill out the plug-in ecosystem.
I moved my personal projects to Nova, and it's screamingly fast. But I still have to use VS for work, and even though I only have four plug-ins, the difference is like pouring water, versus pouring honey.
If vscode slowed down for you it might mean you installed too many extensions.
Personally it feels just as fast or faster than before. Especially with things like the mentioned bracket colorizer beinf built in compared to the extension I was previously using.
compared to what? VsCode is slower than vim without plugins, but it's not slower than anything that has feature parity. VsCode is closer in functionality to an IDE than it is to a text editor, and in that context it is very snappy.
I wish people criticising vscode's slowness would give faster options. It can't be any Jetbrains ide because I've used them all and they can be slow as hell, and buggy especially when pulling new changes. No wonder they are playing catch up with vscode with their fleet ide.
That really depends. I used it on the same machine and it was fine enough on linux and completely unusable on windows. Same extensions, same project.
That was a few years ago now and I've since moved away due to its performance issues, though ironically I then found myself switching again to Emacs which is definitely slower than VSC
sublime is faster from a text editing perspective. less cursor latency, scroll latency, render latency etc. it is significantly faster, like going from 60hz to 120hz.
that being said i use vscode due to the remote ssh stuff which is pretty handy. took me a while to get used to the latency everywhere.
I use vscode for interactive python development with Jupyter notebooks and live markdown rendering, and developing on WSL on windows. Does sublime support that? Vscode has the advantage that virtually every programming language and functionality you can think of, it has a plugin for it. Does sublime have similar support?
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.