4 ms·

It's dumping the so-called "XUL/XPCOM extensions", so that's an extension API. The UI toolkit XUL, they'll continue to use. There are some long-term investigat

It's dumping the so-called "XUL/XPCOM extensions", so that's an extension API. The UI toolkit XUL, they'll continue to use. There are some long-term investigations into using HTML/JS/CSS for the UI [1], but for the moment, the performance difference is still too much. [1]: https://github.com/browserhtml/browserhtml https://github.com/browserhtml/browserhtml

btrask 9y ago
Why is HTML slower than XUL? I thought XUL was pretty much just a weird version of HTML, possibly with more native toolkit support. Is it because XUL is being used from C++ rather than JS? (I checked the browser.html issue tracker but most of their perf bugs seemed to be resolved.)
- MBCook 9y ago
  It may also be that XUL is more restrictive or less forgiving. By not having to handle as many edge cases they can skip a lot of code and speed things up. This is just a guess on my part.
- Yoric 9y ago
  I remember, for instance, that XUL was highly optimized to not create DOM nodes for huge/infinite lists/trees/... Last time I heard about someone attempting to implement these optimizations with comparable APIs in HTML5, the results were ok, but not nearly as good. That was a few years ago, results may be obsolete, of course.
  - fabrice_d 9y ago
    Ha, the xul tree and it's virtual view... Someone (working now at Apple) wrote a super fast list component in HTML for Firefox OS so this can definitely be done.
  - hendersoon 9y ago
    Not sure which APIs you're referring to, but the Vivaldi browser UI is largely rendered in HTML5 and its performance feels native to me.
- digi_owl 9y ago
  I suspect it's because the XUL used in Firefox and later is not "pure". I seem to recall that one of the big "optimizations" that FF did compared to the mozilla suite (these days known as Seamonkey) was to translate a bunch of UI elements into native equivalents rather than drawing it all from XUL. Thus replacing that with HTML may well be closer to reverting to the pre-FF XUL way.

btrask 9y ago

Why is HTML slower than XUL? I thought XUL was pretty much just a weird version of HTML, possibly with more native toolkit support. Is it because XUL is being used from C++ rather than JS? (I checked the browser.html issue tracker but most of their perf bugs seemed to be resolved.)

MBCook 9y ago
It may also be that XUL is more restrictive or less forgiving. By not having to handle as many edge cases they can skip a lot of code and speed things up. This is just a guess on my part.
Yoric 9y ago
I remember, for instance, that XUL was highly optimized to not create DOM nodes for huge/infinite lists/trees/... Last time I heard about someone attempting to implement these optimizations with comparable APIs in HTML5, the results were ok, but not nearly as good. That was a few years ago, results may be obsolete, of course.
- fabrice_d 9y ago
  Ha, the xul tree and it's virtual view... Someone (working now at Apple) wrote a super fast list component in HTML for Firefox OS so this can definitely be done.
- hendersoon 9y ago
  Not sure which APIs you're referring to, but the Vivaldi browser UI is largely rendered in HTML5 and its performance feels native to me.
digi_owl 9y ago
I suspect it's because the XUL used in Firefox and later is not "pure". I seem to recall that one of the big "optimizations" that FF did compared to the mozilla suite (these days known as Seamonkey) was to translate a bunch of UI elements into native equivalents rather than drawing it all from XUL. Thus replacing that with HTML may well be closer to reverting to the pre-FF XUL way.