6 ms·

Really begs the question what Visual Studio Code did right and what Atom did wrong.

bogwog 4y ago
I didn’t use Atom much, but I think it’s obvious that the primary reason it died was because Microsoft decided to make their own competing editor, and then bought the parent company of Atom. It wasn’t exactly the most popular editor at the time, but it did still have some users. 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.
- mynameisvlad 4y ago
  > the primary reason it died was because Microsoft decided to make their own competing editor > 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.
  - bogwog 4y ago
    I mean that Microsoft's acquisition of Github had nothing to do with Atom whatsoever (I assume), but the acquisition was the final nail in the coffin for it. Would it have survived if Microsoft didn't acquire Github? It's possible, however unlikely. But after the acquisition? Not a chance.
  - pygy_ 4y ago
    Chronology. VSCode ate Atom's lunch before MS purchased GH.
- akagusu 4y ago
  Glad to see that someone remembered FreeHand. It was much better than Ilustrator, this is why Adobe killed it.
  - bogwog 4y ago
    I don't know what's worse, that Adobe would do something so shamelessly anti-consumer and anti-competitive, or that the FTC did nothing to stop such an obviously bad acquisition.
    - akagusu 4y ago
      Today we can clearly see that as anti-competitive and anti-consumer acquisition, but at time, I guarantee you the FTC saw the agreement as business as usual, since it does not know how to regulate tech companies even today.
avrionov 4y ago
The first thing which Visual Studio Code did right was the better performance. The initial reaction to Atom was that it was very promising, but very slow. The second big innovation was the language server protocol.This allowed any language to be supported by VS Code.
- radus 4y ago
  Third, for me at least: Remote Extensions. That suite of extensions including SSH WSL, and Container support made things I was already doing frictionless.
  - fendy3002 4y ago
    Integrated terminal from the get go, built in git interface, and the latest live share.
wiseowise 4y ago
LSP, better performance, better defaults, better plugins ecosystem, better (subjectively) UI.
Santosh83 4y ago
MS poured developers at VS Code which resulted in it blowing away Atom pretty soon in terms of performance. Soon devs started migrating to VSC, plugin ecosystem started accreting, and gradually people just forgot about Atom. It is not that Atom did anything horrendously wrong. If the same dev effort had been put into it that VSC got, am pretty sure it could've become almost as good now. Maybe even better in certain respects.
- jahewson 4y ago
  I don’t think that’s true. I used VSCode when it was first released and the team was just a dozen people in Switzerland. The performance was blazing.
jacquesc 4y ago
Speed. I used Atom for a couple years, but quickly switched to VSCode once it was viable as it was the first electron editor to actually be "fast enough" for me.
WorldMaker 4y ago
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.
hansonw 4y ago
(Note: I worked on https://ide.atom.io https://ide.atom.io and Facebook's Nuclide team). 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-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.

I didn’t use Atom much, but I think it’s obvious that the primary reason it died was because Microsoft decided to make their own competing editor, and then bought the parent company of Atom. It wasn’t exactly the most popular editor at the time, but it did still have some users. 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.

mynameisvlad 4y ago
> the primary reason it died was because Microsoft decided to make their own competing editor > 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.
- bogwog 4y ago
  I mean that Microsoft's acquisition of Github had nothing to do with Atom whatsoever (I assume), but the acquisition was the final nail in the coffin for it. Would it have survived if Microsoft didn't acquire Github? It's possible, however unlikely. But after the acquisition? Not a chance.
- pygy_ 4y ago
  Chronology. VSCode ate Atom's lunch before MS purchased GH.
akagusu 4y ago
Glad to see that someone remembered FreeHand. It was much better than Ilustrator, this is why Adobe killed it.
- bogwog 4y ago
  I don't know what's worse, that Adobe would do something so shamelessly anti-consumer and anti-competitive, or that the FTC did nothing to stop such an obviously bad acquisition.
  - akagusu 4y ago
    Today we can clearly see that as anti-competitive and anti-consumer acquisition, but at time, I guarantee you the FTC saw the agreement as business as usual, since it does not know how to regulate tech companies even today.

avrionov 4y ago

The first thing which Visual Studio Code did right was the better performance. The initial reaction to Atom was that it was very promising, but very slow. The second big innovation was the language server protocol.This allowed any language to be supported by VS Code.

radus 4y ago
Third, for me at least: Remote Extensions. That suite of extensions including SSH WSL, and Container support made things I was already doing frictionless.
- fendy3002 4y ago
  Integrated terminal from the get go, built in git interface, and the latest live share.

wiseowise 4y ago

LSP, better performance, better defaults, better plugins ecosystem, better (subjectively) UI.

Santosh83 4y ago

MS poured developers at VS Code which resulted in it blowing away Atom pretty soon in terms of performance. Soon devs started migrating to VSC, plugin ecosystem started accreting, and gradually people just forgot about Atom. It is not that Atom did anything horrendously wrong. If the same dev effort had been put into it that VSC got, am pretty sure it could've become almost as good now. Maybe even better in certain respects.

jahewson 4y ago
I don’t think that’s true. I used VSCode when it was first released and the team was just a dozen people in Switzerland. The performance was blazing.

jacquesc 4y ago

Speed. I used Atom for a couple years, but quickly switched to VSCode once it was viable as it was the first electron editor to actually be "fast enough" for me.

WorldMaker 4y ago

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.

hansonw 4y ago

(Note: I worked on https://ide.atom.io https://ide.atom.io and Facebook's Nuclide team). 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-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.