Revisiting how we build Firefox

David Rajchenbach-Teller dteller at
Thu Jul 9 06:43:50 UTC 2015

Hi Enrico,

A few answers inline.

On 09/07/15 01:16, Enrico Weigelt, metux IT consult wrote:
>> Firefox is built on web technologies*, but we could do a much better
>> job of capitalizing on that.
> I doubt that. IMHO, a browser is just yet another application, just
> like dozens of others, and it should be handled that way - especially
> when it comes to deployment, etc.
> And yes: I'm strictly opposed to applications updating themselves
> (or even just components of / extensions for itself) - these things
> should run entirely through the OS'es/distro's package management.
> It's even a major security issue.

Unfortunately, outside of Linux/BSD (and even then, not all distros), I
haven't seen any OS that does this correctly. So, for the time being,
the burden still falls on the shoulders of applications - in particular
the browser, since it plays host itself to a number of sub-applications
(add-ons, installable web apps, general web apps).

Let's have this discussion again once Windows and MacOS X are up to the


>> *The second thread was about removing that asterisk from “web
>> technologies”.  Back in the early Mozilla days, XUL was our attempt to
>> fill the gaps HTML had at for building large-scale web applications.
>> Over time, the web - and app development for the web - has evolved its
>> own set of standards and technologies; we should follow it.


>> Performance problems go unfixed and it creates a lot of unnecessary
>> complexity within Gecko.
> Does it need to be within Gecko at all ?
> IMHO, the problem domains are entirely different. Common topics (eg.
> graphics rendering, XML parsing, js, etc) should belong into their
> own, separate and generic modules anyways.

Well, they are in separate and generic modules. XML parsing is handled
by expat + DOMParser, JS is handled by SpiderMonkey, etc.

The problem at hand is that Gecko needs to handle both the layout of
XUL+CSS and that of HTML+CSS, because we only have a single layout
engine, because of choices made 15 years ago.

Now, it might be possible to fork Gecko into Gecko-HTML (and plenty of
XML that also needs to be supported) and Gecko-XUL, but that's lots of
work, especially for a technology that we have mostly stopped supporting
years ago.

>> How does this affect add-on developers?
> How does it affect usability ?
> I would really hate to have FF's UI look and feel like some web app.

To some extent, this has been the case forever. Gecko applications have
always relied upon XUL and lots of hacks to make the controls look and
feel native.

But yes, you are right that this is an important factor to take into


David Rajchenbach-Teller, PhD
 Performance Team, Mozilla

More information about the firefox-dev mailing list