5 ms·

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 virtua

by jd3 5y ago

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. [0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL/tree https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... [1]: https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGfWH5Gn4RMKKFPaPrGpZo/edit https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGf... [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1446341 https://bugzilla.mozilla.org/show_bug.cgi?id=1446341 [3]: chrome://browser/content/places/places.xhtml [4]: https://www.thunderbird.net/ https://www.thunderbird.net/ [5]: https://www.seamonkey-project.org/ https://www.seamonkey-project.org/

jd3 5y ago
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 https://imgur.com/a/abhYoW8 https://imgur.com/a/abhYoW8
- lol768 5y ago
  Yeah it's a real shame it's all moving to HTML/JS for the chrome & e.g. devtools, even if it's more "maintainable".
  - jd3 5y ago
    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. https://imgur.com/a/JZoSTXf https://imgur.com/a/JZoSTXf [0]: https://addons.thunderbird.net/en-us/firefox/addon/dom-inspector-6622/ https://addons.thunderbird.net/en-us/firefox/addon/dom-inspe... [1]: https://addons.thunderbird.net/en-us/firefox/addon/javascript-debugger/ https://addons.thunderbird.net/en-us/firefox/addon/javascrip...
    - cxr 5y ago
      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.
    - watersb 5y ago
      Venkman!
  - 5y ago
- bscphil 5y ago
  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.
alisonkisk 5y ago
Why can't XUL vs DOM just be the same data with a fast C++ API and a slow JS API?
- jd3 5y ago
  > 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." [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsITreeView https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/... [1]: https://searchfox.org/mozilla-central/source/layout/xul/tree/nsITreeView.idl https://searchfox.org/mozilla-central/source/layout/xul/tree... [2]: https://searchfox.org/mozilla-central/source/layout/xul/tree/ https://searchfox.org/mozilla-central/source/layout/xul/tree... [3]: https://mykzilla.org/2017/03/08/positron-discontinued/#comment-949 https://mykzilla.org/2017/03/08/positron-discontinued/#comme... [4]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM
pcwalton 5y ago
> 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...
jd3 5y ago
for future readers — ironically, there were actually WIP patches to re-implement the XUL tree (nsITreeView) using an HTML5 canvas years ago https://bugzilla.mozilla.org/show_bug.cgi?id=441414#c172 https://bugzilla.mozilla.org/show_bug.cgi?id=441414#c172 --- "What has been will be again, what has been done will be done again; there is nothing new under the sun." —Ecclesiastes 1:9 "pining for a future that never arrived" https://en.wikipedia.org/wiki/Mark_Fisher#Hauntology https://en.wikipedia.org/wiki/Mark_Fisher#Hauntology

by jd3 5y ago

jd3 5y ago

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 https://imgur.com/a/abhYoW8 https://imgur.com/a/abhYoW8

lol768 5y ago
Yeah it's a real shame it's all moving to HTML/JS for the chrome & e.g. devtools, even if it's more "maintainable".
- jd3 5y ago
  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. https://imgur.com/a/JZoSTXf https://imgur.com/a/JZoSTXf [0]: https://addons.thunderbird.net/en-us/firefox/addon/dom-inspector-6622/ https://addons.thunderbird.net/en-us/firefox/addon/dom-inspe... [1]: https://addons.thunderbird.net/en-us/firefox/addon/javascript-debugger/ https://addons.thunderbird.net/en-us/firefox/addon/javascrip...
  - cxr 5y ago
    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.
  - watersb 5y ago
    Venkman!
- 5y ago
bscphil 5y ago
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.

alisonkisk 5y ago

Why can't XUL vs DOM just be the same data with a fast C++ API and a slow JS API?

jd3 5y ago
> 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." [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsITreeView https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/... [1]: https://searchfox.org/mozilla-central/source/layout/xul/tree/nsITreeView.idl https://searchfox.org/mozilla-central/source/layout/xul/tree... [2]: https://searchfox.org/mozilla-central/source/layout/xul/tree/ https://searchfox.org/mozilla-central/source/layout/xul/tree... [3]: https://mykzilla.org/2017/03/08/positron-discontinued/#comment-949 https://mykzilla.org/2017/03/08/positron-discontinued/#comme... [4]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM

pcwalton 5y ago

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

jd3 5y ago

for future readers — ironically, there were actually WIP patches to re-implement the XUL tree (nsITreeView) using an HTML5 canvas years ago https://bugzilla.mozilla.org/show_bug.cgi?id=441414#c172 https://bugzilla.mozilla.org/show_bug.cgi?id=441414#c172 --- "What has been will be again, what has been done will be done again; there is nothing new under the sun." —Ecclesiastes 1:9 "pining for a future that never arrived" https://en.wikipedia.org/wiki/Mark_Fisher#Hauntology https://en.wikipedia.org/wiki/Mark_Fisher#Hauntology