Living in a Go Faster, post-XUL world

Ian Bicking ibicking at
Tue Jul 14 17:08:29 UTC 2015

On Mon, Jul 13, 2015 at 9:13 AM, David Rajchenbach-Teller <
dteller at> wrote:

> ** High-level
> * Get rid of the deprecated (XUL) bits of Gecko in a finite time.
> * Don't break Firefox [1].

I think this is a huge challenge. If we deprecate XUL (meaning we implement
new things in HTML, try to make the amount of Firefox using XUL smaller
over time) then we are increasing the complexity of development, as the
period of transition will be significantly more complex than the status
quo.  An unfinished transition plan will itself significantly add to
complexity, as everyone will constantly have to ask: what is the right way
to do something *today*.  The only win for complexity is when XUL is
actually eliminated, and it might be years *after* XUL is eliminated before
we see a net gain on that investment given the cost of the transition.

If we want to reduce complexity, while simultaneously working on everything
else we want to do in Firefox, my hunch is that we should have a plan in
place that eliminates XUL all at once, rather than deprecate it over time.
That's not easy, but I think we would save time and effort by investing
hundreds, even a thousand or more person-hours into coming up with a
definitive approach – an approach that doesn't add a tax to all ongoing
work, and an approach that reaches a conclusion.

Speculating a bit what that might look like: that kind of approach would
require that the bulk of the work happen as tooling entirely separate from
mozilla-central.  It wouldn't attempt to re-implement all the logic
embodied in XUL, but it would reimagine that logic in a different context.
That might be something like React Native where the markup is turned into
native controls.  Or it might be something like Web Components where XUL
becomes a set of components built on HTML.  Ideally most code could be
converted automatically.  Things that couldn't be converted should at least
be detected, and ideally could be converted by hand in mozilla-central to a
XUL pattern that was more amenable to automatic conversion.  The team might
land linters so that problematic constructs didn't get reintroduced.
Ideally tests that worked pre-conversion would work post-conversion (and
getting those tests passing would be a target), though I would expect that
test fragility would be a serious problem.

Obviously a very hard problem, and I honestly don't have any guess on the
best way to execute any of the many details, but this is my sense of a
process by which we could come to a positive conclusion.

Ian Bicking | Engineering Manager | Firefox Group | Mozilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list