> I had the impression VSCode had the technical superior plugin system

From my very limited exposure to VSCode's plugins, it seems they are a lot more limited in how they can change the editor's behavior compared to elisp code in Emacs[1]; if Atom plugins are similarly flexible, then I'm not sure you can say it's (strictly) technically superior if you can only implement a small subset of what you can do in competitor's system. At most it's better at some tasks and worse at others if this is the case.

[1] I didn't say "Emacs plugins" since there is no distinction between user-written elisp code and core editor elisp code and you don't need to create any plugin project or such, which I think makes for a much more organic and pleasant customization experience.

Technically superior could mean in this case that a rogue plugin does not affect the core editing experience. Having a fixed extension API, if the API is well done, could provide that.

You lose flexibility, you gain stability, discoverability, speed, etc.

I meant superior to Atom and not to Emacs.

As far as I know, the VSCode plugins run in their own process, which makes the editor much more responsive when it loaded many plugins.

I was assuming that Atom extensions were similarly powerful as in Emacs, if that's not the case, then my point is moot.

I agree that restricting what plugins can do can lead to better stability and speed at the expense of extensibility.

> I found it much more performant

Sincere question: Does "more performant" simply mean "faster"?

Oh. sorry.

I meant, I found it much more responsive.