[mastazi]

For me, the tipping point were some Atom bugs that remained open for a long time[1], when I decided I didn't want to deal with those any longer, I went back to Sublime, which is what I was using before - so from my point of view, it is Atom itself that created its own demise. Of course I'm not denying that the competition from VS Code played a part, but at the same time I think that the Atom community could have addressed some UX issues a bit more promptly and maybe Atom would have had a better chance.

[1] in fact I've just checked and at least one of those bugs - #10720 - is still open, almost 4 years after it was created.

[_bxg1]

For me the tipping point was when installing Atom's Flow extension just started tanking performance. Atom had this super open write-whatever-in-JavaScript extension model which led to tons of great options, but it also meant that lots of common performance-intensive things didn't have a proper, coordinated, prescribed channel and were always talking over each other.

Kind of like how Android apps can just do whatever they want, and how that's become a major performance challenge for Google to mitigate. Whereas iOS says "here's how you send push notifications, here's how you do X Y and Z in the background, here's how you do web views, work within these APIs". Those constraints allow the platform to schedule and prioritize things, reuse work, and enforce quality. I don't actually know firsthand that VSCode enforces this kind of model, but I don't see how else they could get the performance they do with arbitrary extensions written in JavaScript.