4 ms·
The only thing I'm worried about is how would it affect performance. Does it mean the UI itself would be rendered using Gecko Engine?
by piyush_soni 11y ago
The only thing I'm worried about is how would it affect performance. Does it mean the UI itself would be rendered using Gecko Engine?
- pcwalton 11y agoIt already is.
- mburns 11y agoXUL is already rendered using Gecko.
- brandonwamboldt 11y agoIt already is. XUL is rendered via Gecko.
- campd 11y agoLike 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.
- M2Ys4U 11y agoIt already is, only the UI is written in XUL.
- toyg 11y agoI 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.
- joshmoz 11y agoThe 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.
- McElroy 11y agoThe 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.