Sad to see this go. I was an early adopter of Atom, and I wrote two extensions for it, one of which while it was still in beta.

The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engineering built around TypeScript, was rapidly taking over.

Of course, the GitHub acquisition was the last straw, but to be fair Atom was already pretty dead by then.

While the Atom project ultimately failed, it did give us Electron and Tree-Sitter, two technologies that will certainly outlive it.

Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins.

That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up quite slow.

VSCode's architecture worked much better in real world configurations, and it turns out better performance wins in the editor space, even if it meant losing certain customizations (up to a limit). The architecture also allowed seamless remote editing, something Atom never could have done.

The interesting thing has always been that both were built on Electron. Atom's developers had built all the tools and primitives needed, they just didn't have the understanding of the long term ecosystem effects of their design.

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn.

VSCode did almost everything right: The choice of TypeScript as the base language (with which VSCode has a symbiotic relationship), the limited, slowly expanding extension API, LSP, the monorepo, the monthly release cadence, the built-in terminal, and the list goes on and on. They turned Electron's strengths into super-strengths, and deftly engineered around Electron's weaknesses. VSCode is the greatest productivity tool in the history of software engineering, and it fully deserves the dominant status it has today.

VSCode is good but as someone who’s been writing software for nearly 40 years, I really feel you’ve over doing the compliments by a long long way.

Compilers, operating systems, browser engines (unfortunately) and reverse engineering proprietary hardware/firmware are all significantly harder challenges than writing an IDE.

in fact there have been excellent IDEs around for decades before VSCode came along. Yes the industry lacked an LSP but that doesn’t mean that languages severs didn’t exist before then, there just wasn’t a standard before so everyone did their own thing.

Having built in terminals isn’t a new innovation either. That is and always has been the norm.

And most of the other accomplishments aren’t any more unique either (eg lots of software projects have monorepos).

It’s ironic that you say VSCode is the greatest productivity tool in the history of software engineering when VSCode is dependent on so many pre-existing technology’s like Electron, web standards, GUI frameworks, compilers, operating systems, device drivers, etc. in the grand scope of the engineering, VSCode occupies a very small fraction of engineering effort and in a niche that was already crowded before it even entered.

Is it the best IDE on the market? some might think so. JetBrains certainly have their fans too. But even if it’s the “best”, it’s extremely hard to argue that it is that far ahead of the competition and that innovative to deserve the accolades you’re describing.

Honestly I’m not a fan of VSCode as a user. It’s too generic and lacks identity (too powerful to edit simple configs); it auto-updates every time I start it; it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations?

If my goal is to program in language X then I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about.

That being said, it’s very stable and performs well—I will give the devs a massive kudos for that. Also if I did a lot of NodeJS dev work it would probably classify as a proper IDE for that.

But all-in-all I would prefer something purpose-built with minimal configuration out the gate for development workloads (C/C++, Java, C#) and a more minimal editor (nano, vim, eMacs, notepad++, geany, etc) for editing configs.

These seems impression by somebody who's not a VSC user at all. Specifically:

> it’s 2022, why not favor GUI configurations?

VSC provides, at all the (four) levels, both GUI and text-based configuration editing.

> JSON is ugly

You can't get any simpler than JSON. The VSC designers have actually been admirably pragmatic, and opted for JSON5-ish, which supports comments and terminal commas (in arrays).

> too powerful to edit simple configs

Editors are complex by nature; other editors are not different.

It is actually quite the opposite; one can edit a subset of options in the GUI, then observe the changed values only in the JSON editor.

> it auto-updates every time I start it

VSC updates once a month, plus once or twice for patch releases in-between. It auto-updates every time if one opens it two/three times per month.

Plugins do auto update, but one can disable this, if they want.

> I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about

There is no default configuration that satisfies all the users; this is not specific to VSC.

Actually, the extensions experience is probably the most polished out there, and this matters, because if one makes something easy to use, users will use that feature more.

If you like JSON that much, obviously you haven't yet seen https://github.com/Enhex/Deco