 |
| Why Did Mozilla Remove XUL Add-Ons? (yoric.github.io) | ||
| recommended by 2 users | 2020 | 399 points by est31 | browsers | original thread | | ||
| 2 users recommended this thread. What they said: |
| jd3 May 12, 2021 | on: Google Docs will now use canvas based rendering | context |
|
tragiclos Feb 19, 2023 | on: Mozilla solves the Manifest V3 puzzle to save ad blockers… | context
I don’t disagree that XUL was great for it’s time, but this offers some interesting perspective on the reasons for its demise: https://news.ycombinator.com/item?id=24231017 |
Thanks for the reply! I'm a big fan of your work. I can only imagine the nightmare of trying to implement two separate XUL <=> HTML/CSS flex/box models in Servo/Rust.
For readers that are unaware, there is also a great blog post breaking down some of these points in finer detail [0][1].
I guess my question is — are there replacements planned for any of the legacy yet performant XPCOM interfaces / XUL elements like nsITreeView/tree? My tl;dr understanding of XUL trees is that the DOM is and always has been too slow to render millions of scrollable rows in a performant manner (bookmarks, thunderbird, etc.). Would it not be possible to re-implement the XUL tree logic in Rust, for example? Is the goal to completely get rid of all non-standards compliant elements in the long-run?
It seems like there will always be some custom elements necessary for a native desktop interface which can never be integrated into HTML...
"I’ve talked about this before, but things like panel, browser, the menu elements (menu, menupopup, menucaption, menuitem, menulist) don’t have HTML equivalents and are important for our desktop browser experience. While we could invent a way to do this in chrome HTML, I don’t think the cost/benefit justifies doing that ahead of the rest of the things in our list." [2]
..., yet I don't see much discussion about this anywhere.
I'm particularly interested because I'm currently working on a XULRunner project where a <tree> is central to the user interface (millions of rows, image column, embedded data, must run on macOS/Windows/Linux/*BSD, etc.), and it's a little alarming that there is an open bugzilla ticket that did not initially mention either the performance nor ecosystem implications (essentially kill Thunderbird, kill SeaMonkey more than it already has been) of its removal.
I think the one part I have trouble with is that implementing a native looking/performant cross-platform desktop UI is still a nightmare and XUL could have potentially been a fantastic desktop-focused superset/companion of/to HTML.
[0]: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...
[1]: https://news.ycombinator.com/item?id=24231017
[2]: https://briangrinstead.com/blog/xbl-replacement-newsletter-2...