3 ms·

I would not trust any claims in this direction. Such things don’t tend to last very long or age very well, because the functionality was being removed for a rea

I would not trust any claims in this direction. Such things don’t tend to last very long or age very well, because the functionality was being removed for a reason, leading to increasingly large portions of the code base diverging, an ever-increasing maintenance burden, and missing out on genuine improvements from upstream. As an example of this sort of thing, consider when Firefox removed XUL extensions (Firefox 57, November 2017). This upset lots of people, and did kill many extensions that just couldn’t exist in the WebExtensions world, and hobble others. But it was done for a reason, and if you compare pre-Quantum and current Firefox you’ll find one of two is faster, more secure and more reliable: and it ain’t the old one. XUL extensions imposed a serious burden and prevented concrete technical improvements. Of course, other changes may have been made that you may or may not like so much (e.g. UI changes), but the removal of XUL/XPCOM has been a good thing for the browser in general. A number of forks retained XUL extensions, but most died fairly quickly because of code base improvements predicated on their removal. There are still a couple around, I think most notably Pale Moon; they’re all now necessarily hard forks. I don’t know what Pale Moon’s more recent web tech feature support is like—I don’t imagine it’s very good, because it can’t take advantage of Firefox’s efforts. https://www.palemoon.org/history.shtml https://www.palemoon.org/history.shtml paints a fairly bleak picture for the future: things have gone badly wrong already, and they admit that the project is in the long term basically untenable as a general web browser. (That entire article is also highly biased in its presentation of the entire thing, fairly heavily anti-Mozilla and anti-browser-vendors-in-general-though-they-frame-it-as-Google.) Such forks also rapidly decay in usefulness in another way: no one makes XUL extensions any more, and probably no one will be making Manifest v2 extensions any more. For a while, the likes of Pale Moon may have allowed you to keep using more extensions, but by now, using Pale Moon means that you get fewer extensions than Firefox, and so they lose their appeal. There are cases where forks succeed in becoming the primary version of the thing; for example, OpenOffice.org has over time essentially died, and its fork LibreOffice has succeeded. MySQL versus MariaDB is mildly similar, though MySQL’s failure is much less stark. There are also cases where forks have succeeded, with divergence of both. There’s even a good one in the web browser world: when Google forked WebKit into Blink. In that case, both engines were improved by the fork, because WebKit had been supporting two different directions to a degree, and now they could pursue their own individual goals with better focus (both were able to remove lots of code), and both had enough investment to survive. Over time, their code bases have become more and more incompatible. —⁂— So… in a few years’ time, probably no reputable Chromium fork will support v2 extensions, and you probably won’t have any reason to want one that does anyway.

guilhas 2y ago
Firefox could absolutely mantain XUL and have improved it's engine, they just chose not, or were ordered by google to do so And as you say several 1 dev forks were able to keep both WebExtensions and XUL for free, why wouldn't the million dollar company spending millions on side quests? What Firefox did was a shoot in the foot, loose active users, and fragment the community for many years. And we can only hope the same happens to Chrome
- chrismorgan 2y ago
  No, the XUL/XPCOM design, by its nature, became harder and harder to maintain, and there are also plenty of very specific and highly desirable technical improvements that it made completely impracticable, and which have been made since then. https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/ https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... is one article about this, and other information floats about the place too.
  - guilhas 2y ago
    That article was wrong in many ways, even more 4 years later, and you can see it in its comments XUL is a core part of Firefox, and can still be re-enabled for addons today https://gir.st/blog/legacyfox.htm https://gir.st/blog/legacyfox.htm https://github.com/akhodakivskiy/VimFx https://github.com/akhodakivskiy/VimFx But I guess only randos on the internet have the technical know-how
    - chrismorgan 2y ago
      > and you can see it in its comments I don’t see any comments on that article? —⁂— You’re missing the picture. All that LegacyFox looks to do is allow loading old-style extension manifests, by converting them to new-style, just with the difference that they’re given unfettered access to internals. This allows you to load the extensions, but doesn’t guarantee that they will work. By the end of 2019, XUL Templates, XUL Overlays, XBL Stylesheets, XUL Documents, and XBL had been removed <https://groups.google.com/g/firefox-dev/c/24SH5R0AcC0/m/B6ScluagAQAJ https://groups.google.com/g/firefox-dev/c/24SH5R0AcC0/m/B6Sc...>. Last year, XUL Layout was finally removed <https://crisal.io/words/2023/03/30/xul-layout-is-gone.html https://crisal.io/words/2023/03/30/xul-layout-is-gone.html>. I haven’t tried actually running any of this stuff, but I get the impression that this means that pretty much no extensions from the 56 era will work any more. Look at VimFx’s changelog <https://github.com/akhodakivskiy/VimFx/blob/master/CHANGELOG.md https://github.com/akhodakivskiy/VimFx/blob/master/CHANGELOG...>, and yeah, regular fixes have been required, with more and more things breaking. This is a pretty good demonstration of what the problem with XPCOM extensions was, as the article pointed out: they had too much access to browser internals, which made it hard for the browser to change things without breaking extensions, and necessary changes just kept on breaking extensions again and again and again, and extension developers were tired of it. In the WebExtension era, extensions almost never break, despite major concrete improvements in the browser having been made that in the past would have broken at least every interesting extension out there. XUL (by which I mean XUL, not XPCOM) isn’t completely gone yet, because it was such a core part of the browser that it takes a long time to kill it completely, but most of what made it it is gone. XPCOM extensions made Firefox unmaintainable. Although they were a great thing, they had to die for Firefox to survive.

guilhas 2y ago

Firefox could absolutely mantain XUL and have improved it's engine, they just chose not, or were ordered by google to do so And as you say several 1 dev forks were able to keep both WebExtensions and XUL for free, why wouldn't the million dollar company spending millions on side quests? What Firefox did was a shoot in the foot, loose active users, and fragment the community for many years. And we can only hope the same happens to Chrome

chrismorgan 2y ago
No, the XUL/XPCOM design, by its nature, became harder and harder to maintain, and there are also plenty of very specific and highly desirable technical improvements that it made completely impracticable, and which have been made since then. https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/ https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... is one article about this, and other information floats about the place too.
- guilhas 2y ago
  That article was wrong in many ways, even more 4 years later, and you can see it in its comments XUL is a core part of Firefox, and can still be re-enabled for addons today https://gir.st/blog/legacyfox.htm https://gir.st/blog/legacyfox.htm https://github.com/akhodakivskiy/VimFx https://github.com/akhodakivskiy/VimFx But I guess only randos on the internet have the technical know-how
  - chrismorgan 2y ago
    > and you can see it in its comments I don’t see any comments on that article? —⁂— You’re missing the picture. All that LegacyFox looks to do is allow loading old-style extension manifests, by converting them to new-style, just with the difference that they’re given unfettered access to internals. This allows you to load the extensions, but doesn’t guarantee that they will work. By the end of 2019, XUL Templates, XUL Overlays, XBL Stylesheets, XUL Documents, and XBL had been removed <https://groups.google.com/g/firefox-dev/c/24SH5R0AcC0/m/B6ScluagAQAJ https://groups.google.com/g/firefox-dev/c/24SH5R0AcC0/m/B6Sc...>. Last year, XUL Layout was finally removed <https://crisal.io/words/2023/03/30/xul-layout-is-gone.html https://crisal.io/words/2023/03/30/xul-layout-is-gone.html>. I haven’t tried actually running any of this stuff, but I get the impression that this means that pretty much no extensions from the 56 era will work any more. Look at VimFx’s changelog <https://github.com/akhodakivskiy/VimFx/blob/master/CHANGELOG.md https://github.com/akhodakivskiy/VimFx/blob/master/CHANGELOG...>, and yeah, regular fixes have been required, with more and more things breaking. This is a pretty good demonstration of what the problem with XPCOM extensions was, as the article pointed out: they had too much access to browser internals, which made it hard for the browser to change things without breaking extensions, and necessary changes just kept on breaking extensions again and again and again, and extension developers were tired of it. In the WebExtension era, extensions almost never break, despite major concrete improvements in the browser having been made that in the past would have broken at least every interesting extension out there. XUL (by which I mean XUL, not XPCOM) isn’t completely gone yet, because it was such a core part of the browser that it takes a long time to kill it completely, but most of what made it it is gone. XPCOM extensions made Firefox unmaintainable. Although they were a great thing, they had to die for Firefox to survive.