VS Code had a really interesting "head start": the core editor (named Monaco) had been built for very early stages of the Azure Portal and then been adopted int

VS Code had a really interesting "head start": the core editor (named Monaco) had been built for very early stages of the Azure Portal and then been adopted into IE 10/11's Developer Tools to replace an aging code viewer/editor. In order to run in Dev Tools it had to run through an extreme gauntlet of some of the web's worst "files": giant one-line minified things, massive multi-megabyte bundles, and so forth. So the Monaco code editor got a huge amount of performance testing and work years before Atom arrived and built Electron. It also sounds like VS Code took a much more measured approach to extension APIs than Atom did. In Atom nearly every part of the product was an extension, which is a great approach to dogfooding extension APIs and making sure everything including the kitchen sink has an extension API, but getting that performant is tough. Whereas VS Code was very careful in the early days in what extension APIs they declared and started from a place of performance first. In many cases if only a single extension doesn't perform well in VS Code you almost don't notice because it's mostly isolated from the rest of application performance. Atom had a lot more situations, from what I heard, where one badly performing extension brought everything to a crawl.