Hacker News Reader

Comment by adam_arthur | Hacker News Reader

VSCode (Electron) is faster than most native desktop IDEs.

Easy enough to disprove those that say browser based apps are inherently slow. Modern JS is significantly more optimized and faster than most other loosely typed runtimes, e.g python.

WebGPU will just close the gap further.

Anyway you can write highly optimized native code and deploy to browser via WASM anyway. No reason at all to deal with OS quirks. WASM compilation will get better and better over time

View on HN

And yet every few days I look at my running processes to see what's chewing up all the memory and CPU and it's either VSCode or Slack. Kill them all and restart with all the same windows open and everything goes back to fine. I don't consider this good performance. (Note: I have never experienced this with IntelliJ)

I use IntelliJ at work and it’s significantly slower than VSCode.

Who knows about memory, but I use modern hardware so not really a concern. Id rather software optimize for responsiveness than minimizing memory use. Computers are only getting cheaper over time, aggressively deflating in real terms

I can see how being more memory constrained might flip the priorities

> I use IntelliJ at work and it’s significantly slower than VSCode.

I hear this a lot, and I don't think it's outright false, but it's a bit like saying a supertanker is slower than a tug.

The capabilities are just so far apart that it's not a good comparison, IMO.

I'm an IntelliJ fan (and customer) so I'll state that for bias, but the sheer volume of things IntelliJ _CAN_ do compared to VSCode I think is just mind boggling. It might be slower, but I think to compare that aspect while not looking at why is not quite useful.

> Who knows about memory, but I use modern hardware so not really a concern.

I don't know what your definition of "modern hardware" is, but if a 32GB machine isn't enough to edit text files and run a glorified IRC without occasionally having to restart everything to reclaim memory, then yes, it really is a concern.

Re: the IntelliJ comparison: to me, IntelliJ feels qualitatively slower on average than VSCode, but VSCode routinely just stops doing anything at all and I have to restart it.

I wonder if the difference is that we're not editing simple text files. Once you're effectively running a compiler on the fly to provide proper tooling then this memory usage isn't the big problem comparatively.

That definitely doesn't explain the difference for me, since in my current position I hardly write any code but I use VSCode constantly for editing plain text and I still see it go resource-nuts once a week. I assume that it has something to do with the fact that opening vscode to edit a single file results in a dozen processes with varying "-type=" arguments. I currently see --type=gpu-process, --type=renderer (x2), --type=zygote (x2), --type=ptyHost, --type=searchService, --type=watcherService, --type=extensionHost, --type=utility, and two processes without a --type argument. Eventually one or more of these processes will go nuts and start chewing CPU endlessly, it'll all go unresponsive, and I'll notice that my memory usage is pegged, then I'll restart the whole lot and everything will be better.

I have to wonder if I'm missing something or not understanding something. I keep seeing "WebGPU will fix it!" as a response to criticism of using HTML5 technology, but to me, using 3D rendering technology to make UI elements more responsive feels a bit like using a rocket launcher to take out a fly?

You can write UIs in native targeting code (C++, Rust etc) and deploy to browser via WASM with WebGPU targeted render logic and get effectively the same render performance as a native built application, but without having to deal with cross-platform issues. If you really want to eek out that marginal extra performance vs writing directly in JS.

The truth is that the perception gap between web apps and native apps only shrinks over time, so that perceived performance matters less and less

VSCode has hardly any functionality a modern IDE has unless you had dozens of extensions and then it slows down

Im able to write Rust with full and fast type hinting/intellisense, auto importing, code formatting. This is one of the highest complexity languages from a rules based perspective.

Where is the slowness?

I work in Monorepos and trying project(s) wide refactors take way more time sometimes hanging. This is Python vs PyCharm (but also involving JS). I’ve not had issues with Rust but my works rust/C is far smaller LOC so haven’t stressed it enough yet. Saying that I still prefer CLion as it has more features and is just as quick (M1 Max 64GB).

All of what you just described is made possible by rust-analyzer not VS Code.

Exactly my point.

The post is about UI being in native for performance reasons, yet most of the processing/heavy logic of an IDE already is, or in a separate thread, even if the UI is in Electron.

At which point you're just discussing the performance gap between Canvas rendering and native graphics, which to a large extent disappears with WebGPU.

But even if you don't use any heavy plugins, it's slower than sublime text.

And most who used SublimeText left it for VSCode, myself included.

Performance differences aren’t that meaningful at the margins. You tend to give up a lot of velocity when you eschew browser based rendering.

JetBrains is far slower than both

A lot of folks using Sublime today were temporary VSCode converts who returned to Sublime after dealing with its performance issues (myself included). I realized after some time that most VSCode extensions can be replaced with CLI utilities that are often more powerful, less resource intensive, and less buggy.

WebGPU is based on how modern 3D APIs were in their version 1.0 back in 2015.

Hardly reducing any gap.

Fine, but VSCode is not an IDE. Compare VSCode with a (native) text editor. Or VSCode plus all the required plugins to match the (maybe unneeded) functionality of a regular IDE.

Reply on news.ycombinator.com