Atom is dead now. Starting today, Atom is dead.
Probably the editor that had most personality ever – I mean, look at the 1.0 announcement!. But with all things Microsoft does, one thing they know how to do REALLY well is – marketing. Microsoft was able to convince the world that Atom is slow, that VSCode is faster, and that the world does not need Atom. These are all lies, but it is what it is.
So, here’s a video of both Atom and VSCodium loading a file (slowed down to 40%). Please, take a note – none of these use tree-sitter, the faster parser of Atom – both use TextMate grammars, and as you can see, VSCodium loads faster but then it takes a while to actually highlight the code and be usable, where Atom loads slower but as soon as it loads, the file is already ready to be edited. This is a 8,000 lines of code Clojure code, by the way:
Syntax highlighting is so fast on both editors that I had to slow down the video to 5% of the original time, to be able to compare both editors:
Atom got this “editor slow” fame because it was released too early. Which, in my view, it was a good thing: it allowed people to familiarize themselves with the idea of a modern, hackable editor, one that was able to mold itself to each programmer’s need. It was also its own demise: it gave time to Microsoft make his own version of an electron-based editor. So the first “public release” of Atom was slow, buggy, and had a horrible type lag, while the first “public release” of VSCode was a faster editor, more polished, etc… even considering all the API limitations that VSCode had, which again, they convinced the developers that it was a good thing: just look how they told the world about bracket pair colorization: they literally wrote in their blog:
The Bracket Pair Colorizer extension is a good example of the power of VS Code’s extensibility and makes heavy use of the Decoration API to colorize brackets
Unfortunately, the non-incremental nature of the Decoration API and missing access to VS Code’s token information causes the Bracket Pair Colorizer extension to be slow on large files
Did you notice that these two lines contradict themselves? If VSCode extensibility is so “powerful”, why exactly it’s “missing access” to something? All these “conflicting info”, and the blatant lie that VSCode is also open-source made Atom be the “secondary citizen” in the world that itself created (Electron) – after all, why two open-source electron-based editors, right?
Even then, the legacy will continue. We forked Atom and decided to keep it from dying. Now, it’s time to shine brighter than ever, under the name Pulsar. Atom was like a brilliant star in the old editor landscape, where modern hackable editors didn’t exist.
But stars don’t die that easily. Even when they collapse, they keep spinning and sometimes they became beautiful beams of rays – like our Pulsar editor. We bumped Electron, removed telemetry, and made it easier to hack on the core. We’re studying a way to have hot reloadable plug-in development, and to speed up the boot, and make the binaries smaller; we already have the editor running on Electron 19, with issues but at least it works; more will come, for sure, and we will have a hackable, modern editor.
A Pulsar indeed was born!