Living in a Go Faster, post-XUL world

David Rajchenbach-Teller dteller at
Tue Jul 14 19:50:20 UTC 2015

Interesting point, but I don't think that your suggested approach would
solve the problem of the transition period. I fear that this would leave
us with:
- something very, very hard to land;
- broken add-ons;
- front-end & add-ons developers who don't know how to code in the new
- few developers with a huge burden of maintaining all of the front-end,
plus the compatibility tool, until they can form replacements.

P.S.: I'm starting to feel that there is no solution that passes all


On 14/07/15 19:08, Ian Bicking wrote:
> On Mon, Jul 13, 2015 at 9:13 AM, David Rajchenbach-Teller
> <dteller at <mailto: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

David Rajchenbach-Teller, PhD
 Performance Team, Mozilla

More information about the firefox-dev mailing list