> 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'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.