It's funny — Google's approach here reminds me of the Netscape/Mozilla XUL tree[0] element.
For those unfamiliar, the XUL tree is a performant 1990s-era virtualized list that is able to render millions to tens of millions of rows of content without slowdown since it gives you the option of rendering internally in Firefox rather than through the DOM.
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.
It's interesting that both Google's canvas bet (Flutter, Docs, etc.) and the Mozilla XUL tree are basically trying to solve a nearly identical problem (DOM nodes are expensive and DOM manipulation is slow) ~20-25 years apart.
> 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.
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.
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.
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].
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!
I really doubt anyone is going to revive those old legacy widgets. That style of widget is flawed and predates MVC-style design, you'll find it becomes very impossible to present non-string data with that tree. Most applications now will want to show arbitrary widgets within the table, and for that they'll use the standard HTML/CSS. I would expect you can do something comparably fast by using a virtualized list in HTML, along with IndexedDB.
I recently wrote a somewhat performant react-virtualized[0] list for a project at work, though it's definitely a bit trickier in plain HTML/JS.
As far as the XUL virtualized tree goes, a couple of Mozilla engineers wrote some examples using plain html/javascript + DOM node manipulation[1]. While promising, I can't imagine that this implementation could ever be as fast as the compiled C++ one[2].
tangential but amusing — the old chrome://global/content/config.{xul/xhtml} used a XUL tree and rendered 0 DOM nodes to display its treechildren whereas the new about:config renders upwards of 4500 <tr> DOM nodes by default
ignoring the fact that you can no longer sort by specific columns (name, status, type, value, etc), you can really feel how slow the new implementation is if you click the "Show Only Modified Preferences" button — the DOM update feels incredibly sluggish whereas both searching and sorting columns in the old xul tree always felt snappy and instantaneous
I use the modern Firefox HTML5/JS dev tools on a daily basis and love the featureset that they provide, though it is equally shocking to compare the feel to that of the old DOM Inspector[0] (and Venkman[1], the old JS debugger), which was a XUL add-on for DOM inspection that used to run in Firefox, Thunderbird, and SeaMonkey.
What feels snappy and instantaneous in DOM Inspector feels somewhat muddy and laggy in the modern devtools.
While I greatly appreciate the amount of features that Mozilla has integrated into the modern (post-firebug) devtools over the years, it is a little sad that the next generation will never get to experience just how fast some narrow aspects of web development used to be.
Thanks for the shoutout to the legacy DOM Inspector (which I used to maintain) and Venkman (which I have both admired and used in anger). When Mozilla decided to put together a devtools team for Firefox 4, I was disappointed when I realized that they weren't going to take any effort to make sure the fruits of their labor sidestepped any of the performance issues that Firebug had exhibited for most of its lifetime. I do want to quibble, though, about the suggestion that this is a matter of XUL+JS versus HTML+JS. I say this even as someone with strong feelings about what a joy XUL was in comparison, and a long-lasting bitterness over the decision (among many) that Mozilla made in mishandling its own future.
WebKit's Web Inspector has for a long time gone with HTML, and in all its incarnations I've ever tried out, it has always been snappier than either Firebug and or the devtools that ships with Firefox.
When making comparisons like this, it's important to keep in mind that you're comparing/contrasting teams and their output, and it's not just a matter of the building blocks they're using. Some teams do better work than others.
Similarly, my understanding is that the TreeStyleTab extension was forced to migrate in the same manner and it can get very sluggish as well when you have a lot of tabs open.
> Why can't XUL vs DOM just be the same data with a fast C++ API and a slow JS API?
This is a great question! I'm not really qualified to answer it, but I'll give it a try.
My understanding is that the XUL tree is fast because it implements the XPCOM C++ nsITreeView[0][1][2] interface.
If you're writing a XULRunner program ...
(Firefox "is distributed as the combination of a Gecko XUL runtime — libxul, other shared libraries, and non-browser-specific resources like those in toolkit/ — plus a Firefox XUL application — mostly just the files in Contents/Resources/browser/, plus the 'firefox' stub executable that loads Gecko and points it at a XUL application", see [3])
..., XPCOM[4] allows you invoke those implemented interface methods directly from JavaScript.
XPCOM is a technology that, since the removal of XUL/XPCOM addons, is inaccessible to everyone except for Mozilla devs and those who write XULRunner programs using `firefox --app /path/to/application.ini`.
So, some XUL elements (like <tree>) implement an XPCOM interface that invokes native C++ (or rust, python, java, etc.) code, which is statically compiled directly into the Gecko XUL runtime.
Modern HTML5 elements, in general, must utilize the native interpreted browser DOM/JavaScript and cannot choose to implement/satisfy an arbitrary internal XPCOM interface. While I'm sure that Mozilla has figured out a way to make these elements fast (C++, Rust, I have no idea), you are always bounded by the limitations of the DOM.
So, my understanding is that, because we are relying on standards-compliant HTML5 elements which mutate the DOM, we cannot specify and implement new XPCOM interfaces ("with a fast C++ API") that could theoretically bypass the DOM — we /must/ rely on the "slow JS API."
For those unfamiliar, the XUL tree is a performant 1990s-era virtualized list that is able to render millions to tens of millions of rows of content without slowdown since it gives you the option of rendering internally in Firefox rather than through the DOM.
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.
It's interesting that both Google's canvas bet (Flutter, Docs, etc.) and the Mozilla XUL tree are basically trying to solve a nearly identical problem (DOM nodes are expensive and DOM manipulation is slow) ~20-25 years apart.
[0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL...
[1]: https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGf...
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1446341
[3]: chrome://browser/content/places/places.xhtml
[4]: https://www.thunderbird.net/
[5]: https://www.seamonkey-project.org/