Much Ado about XULRunner

Yes, there has been a lot of talk about the Mozilla platform lately. This is to be expected considering the hype generated around Sliverlight and Apollo platforms. Most of the discussion is coming from well meaning developers, using (or trying to use) the Mozilla platform to build products. Developers who want to see the open Mozilla platform flourish in the face of closed competitors. I have a special interest in the platform too, its how I ended up working at Mozilla, so I also want to see it succeed.

Yes, Mozilla made an official announcement (Mitchell’s pre-announcement, Shaver’s preemptive-response) about the plan for XULRunner, a physical manifestation of the Mozilla platform. The announcement contains a lot of information and covers many aspects of the Mozilla platform. Mitchell discusses how the platform will be used internally, to how Mozilla will respond to the platform runtimes from Microsoft and Adobe, and everything in-between. The plan specifically covers:

  1. XUL as Language
  2. XULRunner to Support Firefox and Browsing
  3. XULRunner to Support Other Applications
  4. Stand-Alone XULRunner

Yes, there have been a few “sky is falling” responses to the official announcement. It’s my opinion that the responses have been focused too much on one item in the announcement:

The Mozilla Foundation does not plan to invest in a pre-packaged or stand-alone XULRunner at this time. We plan to re-evaluate this as we approach the release of Mozilla 2.

This quote is part of the Stand-Alone XULRunner plan (#4). The news that Mozilla will not be packaging a system-level version of XULRunner is disappointing to some people. I, too, would like to see such a product, but I think people are severely underestimating the amount of work required to make it happen. A shared, system-level component is not an easy thing to do. When multiple applications share a runtime, versioning and upgrading needs to work almost magically, or some applications will break.

Personally, I am far more interested in the first 3 points. There is some really positive information in the other points:

  • Mozilla will continue to invest in XUL. Just look at the XUL section on the Firefox 3 for Developers page. Development focus is primarily on the needs of Firefox, but should also address broader needs (“Specific examples of how this works in practice have been the inclusion of thread-safety patches and graphics patches beyond Firefox requirements …”)
  • Mozilla will continue to develop XULRunner as a platform for delivering Firefox. Anyone tracking the Mozilla 2 development knows that Firefox and XULRunner will be the primary projects. Just because Firefox will not be delivered with a shared, system-level XULRunner does not mean Firefox will not be built on XULRunner.
  • Mozilla will work with XUL application developers to help move the XULRunner platform forward. This includes working on features and bugs that no only add value to Firefox (and Mozilla projects) but also external projects. Downloadable builds of XULRunner will still be available.

XULRunner is not dead. Do not believe words to the contrary. Its time the XULRunner community begins to focus its efforts to move the platform forward and provide less negative, stop energy.

14 Replies to “Much Ado about XULRunner”

  1. “Development focus is primarily on the needs of Firefox, but should also address broader needs”

    This is good to hear at least. There had been some rumblings about dropping anything that wasn’t used by Firefox explicitly as it would be “difficult to test”.

  2. DigDug – Such rumblings are false or taken out of context. More common reasons would be: MoCo resources are not available to push the work through so external resources are needed; or The feaure/patch would put the current codebase at risk due to the amount of testing that would be required to make sure MoCo products were not broken.

  3. “XULRunner is not dead” – cue Monty Python dead parrot sketch.

    But is XULRunner as a platform, published by the Mozilla Foundation for building applications?

    Many of us have committed years of development to the promises that the Mozilla Foundation has made over the past few years (to quote at firefox roadmap from a couple of years ago: Firefox will be one of the most critical delivery vehicles for Gecko and XULRunner technology in 2005) so we’re not in a position to change platforms. But I’m supposed to present a talk in July about what a great platform XUL is ( – should I just pull out?

  4. I wish people would stop living in worlds of all or nothing.

    XULRunner as a JRE-style shared platform is unquestionably a far greater time-sink than creating a shrink-wrap package that’s stable and vaguely QA’d for the purpose of people being able to use/evangelize XR as an off-the-shelf technology to Just Get Stuff Done.

    This is the 21st century, and while it’s nice to not have to download your shared libraries twice, I don’t really think bandwidth and harddrive are the big constraints here anymore.

    Treating XR as a real product (rather than a red-headed stepchild) and giving it real dev & QA resources doesn’t have to be like trying to ski Bandini Mountain and making it the universe conquering object some people might demand.

    I feel like the “we don’t want to make the single XR runtime, it’s hard” argument is just a red herring to distract from the fact that Moz still only commits a half a programmer to issues specific to it (that don’t explicitly overlap FF).

    Making XR significantly easier for people to use than it is today doesn’t have to take a massive amount of effort and doesn’t have to be ignored as an option.

    That is and will likely continue to be the truly irksome point to me throughout all this cognitive dissonance.


  5. Ian – I would also love to see XULRunner ship with Firefox 3 and be shared so other applications can use it. But, I also know that a shared, system-level XR is not the holy grail. I have been through DLL hell on Windows for over a decade. Whether its RichEdit control or MSHTML or ODBC or whatever, something usually got out of sync and screwed an application. The same thing could happen to a shared XR. Its not a show stopper!

    Small applications would really benefit from a shared XR, but larger applications will need the “safety” of a separate runtime. The lack of a shared XR should in no way diminish the power of XUL/JS/XPCOM as a platform. So give your presentation on the greatness of XUL as a platform with a clear conscience!

  6. mig –

    “Making XR significantly easier for people to use than it is today doesn’t have to take a massive amount of effort and doesn’t have to be ignored as an option.”

    I agree completely and will be contacting you guys and others about how to do it.

  7. I’m curious though, how does less than one developer on XULRunner (last I heard) add up to Mitchell’s claim that “The Mozilla Foundation will continue to invest significant amounts in XULRunner [and the Mozilla platform]”?

    Anyone have details to share?

  8. Ah, Ben responds here:

    I got the “less than one developer” idea from the last Mtn View Moz developer day. It is true that many many many people have contributed to Mozilla-as-platform, and it’s good to remember this.

    And while I do have C++ jitsu enough to hack on something like XULRunner, after having fun coding Ruby for the last few years, going back to C++ and XPCOM feels like, well, something ohso unpleasant.

    why’s HacketyHack, for example, is built on Gecko rather than XULRunner, as he thought XULRunner would just complicate the issue and force him to jump through XPCOM hoops.

    I do think HacketyHack is a good example of an app that ought to be really easy to build on top of XULRunner (with a Camping backend and a few widgets and fancy canvas elements), and yet doesn’t seem to be just yet.

Comments are closed.