4 ms·

> I still don't completely understand why Mozilla is/was planning to axe[1][2] it since there's no web-based HTML5/JS replacement (the virtualized "tree" is imp

> I still don't completely understand why Mozilla is/was planning to axe[1][2] it since there's no web-based HTML5/JS replacement (the virtualized "tree" is implemented in C++, iirc) and it's still being actively used in places.{xul/xhtml}[3] and the Thunderbird/SeaMonkey[4][5] products. XUL is a maintenance burden and exacts a development tax on new features (having to make the Servo CSS engine support XUL so that it could be uplifted to Firefox was extremely annoying). It's also full of security problems, as it's written in '90s C++ that nobody is around to maintain properly. Getting rid of it is an inevitability.

jd3 5y ago
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-addons/ https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... [1]: https://news.ycombinator.com/item?id=24231017 https://news.ycombinator.com/item?id=24231017 [2]: https://briangrinstead.com/blog/xbl-replacement-newsletter-20/ https://briangrinstead.com/blog/xbl-replacement-newsletter-2...
- pcwalton 5y ago
  I mean, you probably won't like this answer, but I don't think you should be writing a XUL-based app in 2021 if you want it to be useful, as opposed to for fun. XUL is 25-year old legacy technology, and using it is an exercise in retrocomputing.
  - jd3 5y ago
    Fair enough. Sorry, I should have clarified a bit more — I'm writing a cross-platform desktop application that has a preact[0] frontend (+ a Go backend) using `firefox --app application.ini`. I have been experimenting with performant lists (which is why I brought up the XUL tree — it's currently central to the interface, though not the final implementation for sure) — I'm currently only using the XUL window/menubar elements in order to populate the native macOS menubar. I am a fullstack web dev in my day job, so my goal here is to write a fast, easily extendable UI that I can quickly iterate upon using modern html/js/css/etc. I love gecko and used to write XUL add-ons many years ago, so I'm already familiar with JS code modules, XPCOM, XUL, the internal browser architecture etc. Basically, I'm now using XULRunner (`firefox --app application.ini` as previously mentioned — will eventually be stubbed into a native macOS .app/OS program) as a replacement for Electron / Chromium Embedded Framework[1]. I'm basically doing the same thing as Positron[2]/qbrt[3]. [0]: https://preactjs.com/ https://preactjs.com/ [1]: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework [2]: https://github.com/mozilla/positron https://github.com/mozilla/positron [3]: https://github.com/mozilla/qbrt https://github.com/mozilla/qbrt
  - girvo 5y ago
    While you're definitely correct, I enjoyed working with Komodo IDE which was (is?) built around XUL even up to a few years ago. A neat API for extending and hacking around on it, with quite nice discoverability. I'm sad to see it go, but it makes perfect sense as to why!
  - silon42 5y ago
    Probably still better than anything HTML.
- 5y ago

jd3 5y ago

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-addons/ https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... [1]: https://news.ycombinator.com/item?id=24231017 https://news.ycombinator.com/item?id=24231017 [2]: https://briangrinstead.com/blog/xbl-replacement-newsletter-20/ https://briangrinstead.com/blog/xbl-replacement-newsletter-2...

pcwalton 5y ago
I mean, you probably won't like this answer, but I don't think you should be writing a XUL-based app in 2021 if you want it to be useful, as opposed to for fun. XUL is 25-year old legacy technology, and using it is an exercise in retrocomputing.
- jd3 5y ago
  Fair enough. Sorry, I should have clarified a bit more — I'm writing a cross-platform desktop application that has a preact[0] frontend (+ a Go backend) using `firefox --app application.ini`. I have been experimenting with performant lists (which is why I brought up the XUL tree — it's currently central to the interface, though not the final implementation for sure) — I'm currently only using the XUL window/menubar elements in order to populate the native macOS menubar. I am a fullstack web dev in my day job, so my goal here is to write a fast, easily extendable UI that I can quickly iterate upon using modern html/js/css/etc. I love gecko and used to write XUL add-ons many years ago, so I'm already familiar with JS code modules, XPCOM, XUL, the internal browser architecture etc. Basically, I'm now using XULRunner (`firefox --app application.ini` as previously mentioned — will eventually be stubbed into a native macOS .app/OS program) as a replacement for Electron / Chromium Embedded Framework[1]. I'm basically doing the same thing as Positron[2]/qbrt[3]. [0]: https://preactjs.com/ https://preactjs.com/ [1]: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework [2]: https://github.com/mozilla/positron https://github.com/mozilla/positron [3]: https://github.com/mozilla/qbrt https://github.com/mozilla/qbrt
- girvo 5y ago
  While you're definitely correct, I enjoyed working with Komodo IDE which was (is?) built around XUL even up to a few years ago. A neat API for extending and hacking around on it, with quite nice discoverability. I'm sad to see it go, but it makes perfect sense as to why!
- silon42 5y ago
  Probably still better than anything HTML.
5y ago