Well, that sounds like the historical Firefox. If you look at the source code of Firefox, just about everything except Gecko is a XUL add-on. Worked like a charm for the first 10 years, not so much afterwards because it became a maintenance nightmare.

That's actually the main reason for which Firefox is moving away from XUL add-ons and towards more restricted WebExtensions.

> If you look at the source code of Firefox, just about everything except Gecko is a XUL add-on

That's not really true at all. Most of the Firefox UI was written in JS (and XUL and XBL), but not as add-ons.

It would have been great if it were true, because not only do you get the reconfigurability the parent commenter writes about, but there are even better advantages: it would also have meant the Firefox team themselves would have had to confront the poor APIs exposed to extension authors and the poor practices about breaking things. The reality is everyone just touched browser.js (or what have you) to make it do what they wanted.† Had that not been the case, the deprecation of old-style toolkit add-ons might have happened long ago and a good replacement created. What happened instead is the worst from both ends: a sickly add-ons ecosystem built on top of fragile XUL-based extensions hobbled along for years, and now that they are obsoleted, they are given a replacement that is decidedly not good.

When Robcee announced he'd gotten the imprimatur to ship devtools with Firefox, I made an impassioned plea for it to be developed and shipped it as a built-in add-on, for exactly these reasons, and because it would have allowed faster development iteration and provided an easier contribution path (no need to ever waste hours rebuilding nightly, or asking for the same from a casual contributor who wants to submit a patch but doesn't work for a manager with an @mozilla.com address). No dice.

† Not to mention tons of XPCOM junk not related to rendering or parsing or the JS runtime that was nevertheless implemented in C++ and would need updates to the core if ever wanting to anything non-trivial.

That sounds like a dream in many respects, but also, by analogy with the size of laptops where every part is customiseable and swappable, like it could be very, very slow or crash-prone. Much of the bugginess of Windows comes from its need to accommodate all possible combinations of bizarre hardware offerings; and much of the "It Just Works" of (some) Apple products comes from the tightly integrated nature of their technology stacks.

I don't really agree with that analogy. Dealing with hardware versus software is vastly different. Demanding driver updates from manufacturers, and then enforcing them onto users is real messy compared to changing an API (with reasonable heads up) and expecting extension developers to adhere or become incompatible.

> Dealing with hardware versus software is vastly different.

I agree; it's important not to read too much (which may be anything!) into the analogy. I just meant that there's a trade-off between flexibility and optimisation, and mentioned the first example of that trade-off that came to mind.

Sounds like Atom. It would probably have terrible performance issues.

Isn't the problem with Electron that any app built with it spawns a full browser runtime? Doesn't seem to be a problem if the app in question is in fact a browser. More like a necessity really.

One problem with this is that if extensions need to be sandboxed from the user, the browser, and each other. Therefore you'r proposing running a process for each part of the browser.