Really begs the question what Visual Studio Code did right and what Atom did wrong.
The second big innovation was the language server protocol.This allowed any language to be supported by VS Code.
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.
On the topic of performance - one of the architecture decisions that VSCode nailed was the 'extension host' (https://code.visualstudio.com/api/advanced-topics/extension-...): all VSCode extensions are sandboxed in a child Node process, and can only communicate back with the main IDE process via the VSCode API. This has huge benefits for performance:
(1) extensions can never block editor startup. this was a huge problem for Atom as package loads were startup blocking and it wasn't uncommon to have multi-second startup times with lots of packages installed - especially due to the fact that JS packages typically repeat dependencies, resulting in tons of bloat. Also extension authors are rarely performance-conscious
(2) extension code can never block the core rendering thread, another huge problem in Atom - you'd often have stuttering/frame drops if extensions were doing blocking work on character or cursor changes, which was more often the case than not..
The tradeoff of course is that VSCode extensions are very limited in the set of UI customizations they can make but MS did a very good job of designing their APIs to be sufficiently extensible in this aspect (i.e. having APIs for extensions to hook into all core IDE features). Atom's extension ecosystem was much more fragmented resulting in dependency/versioning hell.
As a side note, another benefit of the extension host model is how it enables extensions to semi-magically work on remote filesystems (including inside WSL) without needing complete rewrites.
Reminds me of how Adobe killed off FreeHand (the only competitor to Illustrator at the time) by buying the parent company and then halting development.
Of course, Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways, but I still think it’s interesting to see the similarities to the Adobe situation.
> Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways
How can Microsoft both give zero shits because it was effectively dead, while also still being the primary reason it died? That seems to be a chicken-egg problem.
Would it have survived if Microsoft didn't acquire Github? It's possible, however unlikely. But after the acquisition? Not a chance.