4 ms·

Atom used a very different extension model than Visual Studio Code. Atom was designed more in the "everything is an extension" mold and even "core" functionalit

Atom used a very different extension model than Visual Studio Code. Atom was designed more in the "everything is an extension" mold and even "core" functionality could be replaced or extended in ways that VS Code likely will never allow. On the one hand greater potential power, on the other hand more potential responsibility (Atom did have some notorious performance issues with comparison to VS Code and "everything is an extension" can be hard to performance adjust at scale). 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.

brundolf 4y ago
Yeah- its open extensions model was a neat idea, but in practice it made it slow, buggy, and complicated to configure (extensions would have dependencies on other extensions, etc). I really tried to stick with it, but as soon as I tried VSCode I sighed a breath of relief and knew I couldn't go back 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.
sporedro 4y ago
I don’t know how to phrase this and it might be a bit of a ramble, but your reply is something I’ve been thinking about with atom. I personally hated eclipse, due to it feeling constantly like everything was it’s own package and not really working together, but recently was trying out emacs, and was quite impressed. Atoms philosophy sorta reminds me of the two where it’s “everything is an extension”. 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.
- petre 4y ago
  It's working out fine and doesn't have all the visual annoyances and wheel scrolling issues that CS Code has. I use it since version 1.1. I tried VS Codium this week but reverted back to Atom after reading about the RCE and not being impressed with it. I also want an editor, not an IDE, no Git integration as I don't use Git. And yes, it is slower compared to VS Code. Next I'm going to give Emacs a shot.
- nsonha 4y ago
  it's technically true that VSCode is less customizable but honestly who cares? Both of these editors are so minimal in their design that UI customization doesn't mean much.
- WorldMaker 4y ago
  > 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? 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.
piskerpan 4y ago
Knowing the history of Firefox, XUL extensions and their demise, this feels more of a limitation. 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.
- cardanome 4y ago
  I mean it works for both emacs and vim which are even more extensible. 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.
  - piskerpan 4y ago
    Sorry I don’t think Firefox lost because of extensions. Nobody cared except us. They lost because on Google advertised the living * out of Chrome. Firefox couldn’t compete regardless, it offered an inferior product out of the box. Again, HN users are not the majority of internet users, which are counted in the billions.

brundolf 4y ago

Yeah- its open extensions model was a neat idea, but in practice it made it slow, buggy, and complicated to configure (extensions would have dependencies on other extensions, etc). I really tried to stick with it, but as soon as I tried VSCode I sighed a breath of relief and knew I couldn't go back 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.

sporedro 4y ago

I don’t know how to phrase this and it might be a bit of a ramble, but your reply is something I’ve been thinking about with atom. I personally hated eclipse, due to it feeling constantly like everything was it’s own package and not really working together, but recently was trying out emacs, and was quite impressed. Atoms philosophy sorta reminds me of the two where it’s “everything is an extension”. 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.

petre 4y ago
It's working out fine and doesn't have all the visual annoyances and wheel scrolling issues that CS Code has. I use it since version 1.1. I tried VS Codium this week but reverted back to Atom after reading about the RCE and not being impressed with it. I also want an editor, not an IDE, no Git integration as I don't use Git. And yes, it is slower compared to VS Code. Next I'm going to give Emacs a shot.
nsonha 4y ago
it's technically true that VSCode is less customizable but honestly who cares? Both of these editors are so minimal in their design that UI customization doesn't mean much.
WorldMaker 4y ago
> 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? 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.

piskerpan 4y ago

Knowing the history of Firefox, XUL extensions and their demise, this feels more of a limitation. 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.

cardanome 4y ago
I mean it works for both emacs and vim which are even more extensible. 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.
- piskerpan 4y ago
  Sorry I don’t think Firefox lost because of extensions. Nobody cared except us. They lost because on Google advertised the living * out of Chrome. Firefox couldn’t compete regardless, it offered an inferior product out of the box. Again, HN users are not the majority of internet users, which are counted in the billions.