Like pcwalton said, we already use Gecko to render the UI. But we're using a less well-optimized, less well-maintained corner of Gecko.

Improving performance is an explicit goal of this work.

The Firefox (Desktop) UI is already rendered using Gecko. It has been that way since the beginning.

Mozilla spends much more time optimizing HTML and other Web content tech than it does optimizing XUL and XBL. I wouldn't worry too much about this project slowing down Firefox. It might even speed it up a bit.

The e-mail seems to suggest that it would improve performance.

>Because XUL and XBL aren’t web technologies, they don’t get the same platform attention that HTML does (for good reason!). Performance problems go unfixed and it creates a lot of unnecessary complexity within Gecko. It’s harder for even experienced web developers to get up to speed. It’s further from the web, and that doesn’t help anybody.

I believe that's already the case, although it uses XUL-specific code paths in Gecko.

In terms of performance -- there is no deep reason for it being slower, but of course the code might end up being a bit less optimized compared to stuff that has been battle-tested for 15 years. On the other hand, getting rid of XUL could deliver dramatic results. It's all speculation really, but there is no real technical reason for "XUL-less FF" to be incredibly slower than current offering.

It already is. XUL is rendered via Gecko.

XUL is already rendered using Gecko.

It already is.

It already is, only the UI is written in XUL.