Given this Pulsar page makes a big deal about trying to preserve the package source (list of extensions), the different extension model and history/long-tail of community extensions was probably important to them.
I think the most egregious example was having two competing IDE hints extensions (not the content, just the GUI). They could both be enabled and they could fight each other or overlay each other if they were. Some language extensions then depended on one, and some depended on the other. It was kind of a mess.
I guess my question is, is how did this work out for it? I never gave atom a try, but did it feel like everything sorta worked together? Or was it more of a eclipse feeling where every package feels like it’s own separate object?
Vscode is a decent out of box experience but it’s custom ability is rather limited imo. Would love to give atom a try if this community version succeeds at all.
The obvious short answer here is: it obviously didn't work out for Atom. It wasn't able to compete with VS Code in the general marketplace, many people who tried to use Atom thought it was slow and buggy (there are examples in other comments near here, such as dueling tooltips plugins), and then eventually GitHub and Microsoft decided to pool all their official resources into VS Code and sunset Atom.
Pulsar linked here is an attempt to preserve what's left of Atom's open source community and I wish them luck, but they are maybe going to need a lot of it with competition like VS Code. Though admittedly Eclipse is an interesting comparison here because Eclipse still lives on, after several times where people assumed Eclipse was over with and the competition clearly winning. Some big companies still use Eclipse for all sorts of reasons.
For those who don't know, Firefox couldn't innovate because any change to the UI broke half the extension ecosystem. This is what happens when you give carte blanche to third party developers on your UI: It's great for the short them.
You shouldn't make any UI changes to text editors anyway if you don't plan on pissing off your power users. Never break compatibility.
As for Firefox, well if I could go back to the XUL based UI, I would do so. I don't think the new UI has improved for power users at all it just looks more "modern" which is fashion not progress.
What did Firefox gain from trying to copy Chrome? They are at a negligible market share and are only kept alive by Google money as alibi competition.
So no, that is not a good example. Moving away from XUL extension was not progress for Firefox, it was the beginning of it's decline becoming the rotting corpse of former ideals that it is now.
Again, HN users are not the majority of internet users, which are counted in the billions.
* Atom was hackable from the ground-up. I use a VS Code extension called Customize UI that allows me to write custom CSS, but Atom supported custom CSS as a first-class feature.
* Nostalgia: Atom was the first text editor I used, and so it has a certain friendliness than other editors can't match.
* Atom One Dark and Atom One Light are the best pair of dark and light code themes I've ever used. I use ports of these themes in other editors, but you can't beat them in their original context.
* I don't love VS Code's whole design language (straight-thin lines and sharp angles, except for some corners, which are curved). But that's probably very much tinged by my other points.
* Atom, of course, matched VS Code on language support and plugin support at one point. You could find extensions for just about any language. (Something that wasn't ever true for Sublime or Textmate, for example.)
* Being truly open source (I would describe VS Code as more open-core).
* Not being the most popular editor. I love supporting the underdog in my software choices as a way of encouraging innovation and variety in the ecosystem. So if Microsoft makes VS Code so good that no editor can complete with it, I would use VS Code (VSCodium), but I would not be happy about it.
All that said; Atom's dead. Since the Microsoft acquisition, development has stalled. Atom's gotten increasingly buggy and many many packages were abandoned. As I understand it, there are architectural issues that make it very difficult to fork or maintain. Atom is upstream of Electron (not downstream of it), for example, since Electron was originally extracted from Atom's code, so that makes integrating Electron updates difficult. CoffeeScript (which a lot of Atom is written in) never really caught on. You have a bunch of existing packages, but as mentioned, most of them are unmaintained, so you'd have to rewrite them and it's not clear which ones. Tree-sitter was originally developed for use with Atom, but after most popular programming languages had packages, and they never got rewritten with tree-sitter.
I've been following Lapce. I think they're doing interesting work. Right now the editor is too buggy for me to consider as a daily driver. I've been using Emacs for the past couple of weeks. It exceeds Atom's hackability, but there are still a lot of rough edges in the UI, for someone used to GUI editors.
I didn't mean to write this much. Atom is obviously something that I care about and that I've been thinking about ever since the acquisition.
TL;DR: Some people don't like VS Code, as a personal preference, and other options for GUI text editors are good.
Can't say I felt this way about qbasic.
My only complaint with Atom is about performance. A fresh install of Atom feels normal fast at first, but as I add more plugins, it gradually feels slower. VSCode is better in this regard. Nowadays I mainly use Sublime Text, which is faster than VSCode. I also keep an eye on Lite-XL, which has the potential to be as fast as Sublime Text with a smaller memory footprint.
Fair move would be to put a well visible message into VS Code or their download pages, which informs the user: "If you need to check the build, you probably want VS Codium instead." -- Of course they are not obliged to do that, but meanwhile they are collecting telemetry to no end, from users, who are not informed about their main workhorse of their job. It does not seem right to me.
In general we need more awareness of telemetry, especially from companies like MS. Maybe at some point they will ship some telemetry update which the user "only needs to quickly confirm", before they can hack away and which opts into sharing code with their Copilot thingy. Before you know it, your solutions to problems are shared with other people, who will get a copy of your copy inserted. Lots of scenarios how this could go wrong, even if accidentally.