VSCode is handling a lot of the heavier stuff in C++, but it's still an Electron app, with the sluggishness that comes with it. Compared to things like nvim or sublime text 3, VSCode performance ranges from "meh" to "ugh".
It's true that VSCode is somewhat usable (unlike Atom). However, it is not impressive, despite so much effort being put into its performance (including a vast amount of core code being written in C++).
For this reason, I take VSCode as the perfect counter-argument to Electron: It shows you that the absolute best case is somewhere between poor and mediocre responsiveness with pretty high resource consumption for the task.
(Anyone who finds VSCode to be snappy is either too used to the sluggishness of web, unfamiliar with how a responsive application feels, or has just thrown so much hardware at the problem that it ends up being decent.)
I mean I use vs code daily and don't think it's any less "snappy" than a native app. Quite the opposite really, Chromium's rendering engine is faster than most native cross platform toolkits. The memory consumption doesn't bother me either or come anywhere close to bottlenecking me, because I'm a professional using professional hardware.
Sublime is also pretty featureless compared to VSCode as well.
> Chromium's rendering engine is faster than most native cross platform toolkits.
Which toolkits are you referring to, and do you truly just mean the renderer, or the entire engine?
Chromiums renderer is pretty fast. Not as fast as direct rendering like Sublime Text does, but for very complex scenes, it will beat Gtk and Qt.
However, it's expensive to build scenegraphs for it (needed on every change), and partial updates are far more expensive than they need to be.
The end result is that, for something like an editor, Gtk and Qt will beat Chromium for responsiveness by a large margin, despite having much less performant renderers for the time being.
(You can get around some of these costs by using WebGL of course, but if you're doing manual rendering you have already thrown most of the reason for Electron out of the window, so why not do it natively where it will be even faster?)
> The memory consumption doesn't bother me either or come anywhere close to bottlenecking me, because I'm a professional using professional hardware.
This is an awful argument. That I have beefy workstation machines doesn't really matter when I'm usually mobile on a low-power laptop.
The difference between using VSCode and sublime/vim is several hours of battery life, and the difference between a comfortable lap and a warm lap.
This idiocy of "it's fine, there's enough resources" is why my colleagues expensive MacBook Pro's are hyperventilating 24/7, and it's a problem for poorer individuals that might not afford a powerful machine.
> Sublime is also pretty featureless compared to VSCode as well.
Matter of taste.
Sublime Text still has a very long list of plugins, and certainly does everything I will ever need an editor to do. I see no reason to pay the penalty of Electron to get support for NyanCat cursor plugins.
VSCode is also pretty featureless if you compare it to vim, and if we pull Emacs into the discussion, VSCode ends up looking more like nano/Notepad.
Its too early in the morning for me to get into a flamewar about this.
So all I'll say is that I get a lot of value out of VS Code as a tool, and I don't think it's slow. I think every point you bring up comes from a lack of experience and knowledge of the tool/platform, and it's not worth arguing about online.
I'm not saying that VS Code is not valuable as a tool - that would be a stupid thing to argue over.
I used VS Code for about a year, and occasionally revisit to reevaluate. Hell, I even gave Atom a (rather unwarranted) fair shot.
What I am evaluating is just performance and resource consumption, which is much worse than it needs to be due to the design choice of using Electron, which has little to nothing to do with the functionality it provides.
For me, the performance makes it uncomfortable to use. Others less fortunate will be experiencing something much worse than I am.
I agree that VSCode is not "slow," at least not when you get used to it and definitely not in comparison to other Electron apps. I used Sublime Text 3 for a long time before Atom became popular. Immediately, I noticed that Atom was nowhere near as snappy as ST3, and was constantly hanging even on opening large folder structures.
VSCode was a breath of fresh air compared to Atom and the extension support was even more impressive. But very recently when I found out about the Sublime LSP package, I decided to give Sublime another look. The snappiness difference between ST3 and VSCode is night and day. Even though by no means does VSCode feels "slow" for my day-to-day work, the small speed improvements of using ST3 compounds to make for a greater experience overall to me.
> I mean I use vs code daily and don't think it's any less "snappy" than a native app. Quite the opposite really, Chromium's rendering engine is faster than most native cross platform toolkits.
it's definitely not. Just adding a `/*` at the top of a file takes a noticeable delay to update the whole text, while it's completely unnoticeable in e.g. QtCreator.
I just took this video on my screen, notice how everything lags in VS Code (left) in contrast with QtC (right) :
What's worse, VS Code uses GPU for its rendering while QtCreator uses a software rasterizer, which should in theory perform less well (in practice, GPU font rendering is definitely not there yet). Both use the same backend for C++ syntax parsing (clang) so the problem is not there.
> it's definitely not. Just adding a `/*` at the top of a file takes a noticeable delay to update the whole text, while it's completely unnoticeable in e.g. QtCreator.
Conversely, Qt Creator is rather anemic and featureless when compared with vscode. I mean, it doesn't even support very basic features such as editing yaml or json files, it barely supports any form of refactoring at all, doesn't support any form of project other than the old hardcoded C++ support piggybacking clang, etc.
Heck, supposedly Qt Creator's main build system is cmake, and it doesn't even allow you to add files to a project without having to hand-tweak CMakeLists.txt files.
Perhaps if Qt Creator offered a fraction of the features already provided by a free text editor such as vscode then we could start to compare sub-milisecond differences in paint times. Until then, unnoticeable differences in performance coupled with far more functionalities make it a non-starter.
I've tried looking in VSCode to test where it would go but cannot find a command that would add a new file to a CMakeLists. File > New file > save as .cpp definitely does not and I don't see a right-click option that would do it.
> , it barely supports any form of refactoring at all,
c'mon, here's my experience with Qt Creator when comparing with VS Code (with the C++ extension installed):
I'll agree that QtC (https://doc.qt.io/qtcreator/creator-editor-refactoring.html) has less than for instance CLion in the refactor department, but than VSC? Maybe with ten additional extensions or so ? But qtc works from the get-go without needing to go fetch plug-ins elsewhere.
Note also how QtC helpfully tells me bugs and issues in my code along me typing, without making typing slower.
In contrast, I really have trouble concentrating with VSC (and also JetBrains IDEs & VC++) operating latency (and that's on a 8c/16t top-end desktop i7).
> and don't think it's any less "snappy" than a native app.
I have tried to adopt vs code multiple times and just end up going back to (n)vim, where opening a file is instantaneous and I never have latency when typing, etc.
However I do find Jetbrains' products like CLion/Goland are pretty nice.
From experience... with today's computer having 16GB+ ram, VSCode is fine. But if you start doing dev work on a 2011 Macbook Air with 4GB ram or even 8GB ram, you quickly notice how much memory electron apps consume. When switching between VSCode to something like Sublime, the consumption is 10X improvement. That is my only beef with Electron apps. It is a way to get something cross-platform extremely fast but with ZERO care for how expensive it is.
I like VSCode but also agree. Once you've felt the speed of native, like Sublime Text 3, especially when opening and working with a lot of files at once, it's really hard to use anything else, IMHO
That said, there are use cases for VSCode that don't really apply to ST3, etc
As long as there's no latency when actually editing text, which is my experience with vscode, I don't think it's that big of an issue. As someone that's moved from vim+plugins to vscode, I'll take the few milliseconds of latency here and there as the price of having an environment where everything just seems to work out of the box, including plugins. Sure vim is snappier, but does it really matter if I have to constantly debug why youcompleteme isn't finding my header files or whatever.
Theoretically that doesn't have to be trade off. Theoretically it's possible to build an editor like vscode with a native interface. In the actual world it doesn't exist for whatever reason, so I'm going to keep using vscode.
Theoretically it's possible to have a not-buggy vim. It's not fair to exclude everyone who is able to configure a more performant editor just because you can't.
Your claim that "in the actual world it doesn't exist" is just not true. Thousands of lifetime vim/emacs users are scratching their heads.
Configuration is maintenance that I'd rather not do, it's not a matter of "can't". I used vim as my main editor for years, and I had it very much configured to my liking. Any time you have to set up plugins for a new language or a new environment though, it can be annoying, which is why I started using vscode as a front-end for neovim. Now I have a nice-feeling well-supported IDE with all the power of vim for editing.
I no longer consider vscode to be an electron app. You would need a ton of expertise and lots of c++ to have your electron apps perform anywhere close to vscode (and you would still be slower than native)
I always see Visual Studio Code trotted out as an example of a relatively fast Electron app. I do use Visual Studio Code (for complicated reasons), but if I were to describe it to someone, the first thing I'd mention is that opening a new window (i.e., the `⇧⌘N` shortcut) is incredibly slow. For this action, it's easily the slowest of any application I use regularly, I can count to three before the window appears, a normal application is ready for input practically instantaneously.
Vscode is pretty snappy and relatively light to the point it's not prohibitively expensive to run it, for example.