Monday, February 15, 2010

What's wrong with Mozilla Jetpack

There's been some interesting discussion recently of "what's wrong with Jetpack" by Laurent Jouanneau, Daniel Glazman, and others (see the long comment thread at the end of Daniel's recent post). The criticisms tend to fall along two major axes:

1. Mozilla Jetpack claims to be a kinder, gentler, easier to learn replacement technology for making Firefox extensions (replacing the existing quirky hodgepodge of XUL+XBL+XHTML technologies), but it abandons XUL totally, which means that extension programmers can't transfer their current XUL skills to the Jetpack dev world, and (more important) Jetpack loses the sophisticated layout model of XUL. In its place we have plain old HTML and CSS.

2. The Jetpack API is bound too closely to the jQuery API with its closure-intensive syntax, its peculiar self-obfuscating '$' notation, and overreliance on method overloading.

One of Jetpack's goals is to democratize Firefox extension programming, liberating it from the hands of the XUL programming elite and bringing FF extension programming into the purview of mere mortals who speak HTML and JavaScript. But it stops short of that goal. In point of fact, Jetpack encourages "magic code" -- closure-ridden one-liners and such -- and expects a fair amount of clairvoyance from programmers when it comes to required imports and other notions. For example, the winning code entry in a recent Jetpack coding competition is all but unreadable (i.e., it's self-obfuscating), with lines like:

let window =

Any API that encourages this kind of code gets a thumbs-down from me, and frankly, at this point, I would probably have to agree with Daniel Glazman when he says that Jetpack "
totally misses its main goal [of] making extension authoring dead simple instead of recreating another programming elite." Wedding itself to jQuery was one of the worst design choices Jetpack's API experts could have made, IMHO. "Clever" syntax doesn't advance an API's cause, any more than secret handshakes advance diplomacy's cause.

There are other criticisms, having to do with things like overuse of imports, wrappedJSObject, lack of localization support, lack of ability to use offline resources, and some odd constructs like jetpack.tabs.focused.raw. But except perhaps for localization, those are not showstoppers. A syntax that encourages brevity over clarity and coolness over maintainability, on the other hand, is definitely a problem. It seems to me we're either going to democratize Firefox extension creation or not. If we are, let's get rid of the secret handshakes and go back to KISS as a design principle.


  1. Hogart1:03 PM

    This feels to me like an argument about code-style preferences. I fail to see how it's "self-obfuscating", or how that winning entry was "unreadable". What would be considered "better"?

  2. I switched to jQuery because there's so much code written for it. Very easy to find plugins, examples, etc because a lot of other developers (of all levels) find it easier to work with.

    The majority of "other people's code" I've encountered to date was very readable.

    In stark contrast to what you've showing above, but then, that's not typical jQuery code. It doesn't look like jQuery API, idioms or naming scheme.

    What it does look like is the insane Mozilla API (aka XPCOM), a horrid object model they layered on top of C, reminiscent of DCOM (MS), but with less tooling support around it.

    Here's what XPCOM looks like outside Jetpack:

  3. Anonymous4:31 PM

    When I had to do some XUL, I hacked nicer interface for getService and friends because I couldn't stand this C++ madness. And added jQuery. Does it mean I will love Jetpack?

  4. As Assaf says, the one-liner you cite is existing XPCOM cruft. It is exactly the kind of thing Jetpack is trying to eliminate.

    Current (pre-reboot) Jetpacks have full access to all of the horrors that normal extensions have. If you see a Jetpack accessing Cc (and alias for Components.classes), that's a warning flag that something is going on that probably does not yet have a friendly API.

  5. The case against JetPack as a democratizing movement is further strengthened by the fact that XUL is in fact NOT replaced by plain old HTML and CSS, but by Javascript only, even though Javascript may easily be considered the most elitist of all frontend development disciplines to begin with. You may be able to emulate the XUL layout model in XHTML using moz-box-flex and related CSS properties, but without stylesheets, indeed without markup, it is simply not practical. The worst design choice of Jetpack was to base it on Javascript in the first place; abandoning declarative languages such as XUL, XBL, XHTML, XML, SVG, XSLT and CSS (plus the more exotic overlay and template languages) while sticking to the "glue" that was merely supposed to bind these technologies together. I am disturbed to see the status of this DHTML-scriptsoup pet project being elevated to official politics, just as I am disturbed to see Personas being pushed to the general public while developers aim at reducing the header area of Firefox by 50% in the upcoming version 4, thus invalidating most of the 35000 Personas submitted to date. Something fishy is going on over at Mozilla. Maybe this whole Mozilla Labs is being run by a rival browser company. This would certainly explain why the "leave a reply" option featured on all project pages has yet to yield a single reply. You suspect they would have noticed by now that the comment system simply doesn't work, especially with all this talk about democracy. I am joking, of course, but since this whole debacle made me switch to WebKit for both my daily browsing and my development ambitions, it is really not that funny.


Please add your comment here!