I think vscode was built with performance in mind from the ground up. Atom on the other hand was focussed on hackability. Down to actual reason, I haven't scanned the source code but have noticed vscode delegates lots of processing to separate child processes that could prevent potential freezing/lockups in the main process/window.

It's not magic by VSCode, other web-based editing components such as the ACE editor are also lightning fast. There are two main reasons:

- VSCode is rendering in the DOM what you see, not what you scroll to.

- VSCode is using the correct datastructures, so an insert of a line at the top, doesn't require updating/relayouting all lines below it, but more likely something like log(n) lines.

And these two reasons you can summarize as the difference between old skool engineers with proper training in datastructures, cache behavior and algorithmic complexity -vs- new skool "full-stack developers" that rely on a billion lines of code they haven't written (or understand) and who mainly script a bit in between. The (wrong) assumption in the recent decade was we don't need to train engineers to understand the algorithmic complexity of their code because 'computers will continue to become faster'. That was never true and never will be true, because an exponentially slow algorithm simply won't ever be fast enough regardless of the amount of transistors. And making something like a simple text editor (without syntax highlighting and all of that -- just being able to edit the code), is actually an easy test to distinguish between the two wildly different skillsets.

I dont see any C++

https://github.com/Microsoft/vscode

VSCode pulls in all sorts of precompiled dependencies during build. e.g. the search is done via RipGrep which is just a binary.

But I agree that it is mostly typescript through and through, they just have implemented basically everything as a non-blocking promise.

And most importantly, the extension system cannot block the UI. It runs in a completely different process also.

The honest answer -- Microsoft has a lot of people with experience in building these things, so they aren't making the typical mistakes that Atom made with their architecture. For example: Atom was rendering dom nodes for your whole file -- not just the parts that were visible. Using the DOM as a stateful container of all that could be visible does not scale really well.

Compare to something like the ACE editor (an OSS editing component that you can plug into any website) which is lightning fast -- it only renders what you see though -- but the filesize is not at all relevant to the performance.

These are all techniques that people who ever wrote complex UI toolkits are incredible aware of. I don't think that describes anybody who worked on ATOM ever, which means they just have to relearn and re invent this stuff until they get it right.

Generally, these days a lot of developers get a lot of experience combining existing technologies. Proper engineering skills, or even being aware of the data structures you are using and their algorithmic complexity, how cache friendly it is -- all of this is prioritized much less now.

So Atom answers a simply question. Has hardware become significantly fast to not care about proper engineering? No, not really and it never will. If your datastructure is structured in a such a way that inserting a line all the way at the top requires a relayout of every line below that, for example, you will run into real limits.

VSC streamlines the data it needs to load, doing the least amount possible in hot paths as far as I know. They also multi-thread on startup so it is perceived as being quicker to boot up.

Honestly I use both often and just the startup makes it seem faster. Just the startup alone makes such a large difference to perception.