Jetpack and making the UI world adopt HTML5

(Disclaimer: I mailed the Jetpack people a rather long document of comments at the end of november. So it's not something popping out suddenly. And it's not an attack, I am commenting here because I have the gut feeling Jetpack - whatever its fate - is something we'll need in the future of UI design and extensibility.)

I have many things to say about Jetpack. I like its power, I dislike its syntax. I _really_ dislike its syntax. I think it totally misses its main goal, making extension authoring dead simple instead of recreating another programming elite. I also think the integration of XHTML elements inside a XUL-based UI raises strong UI homogeneity issues (because they don't flex, align or pack like XUL elements) and could severely harm the UI coolness factor of the whole user interface.

If I look at the three winners of the recent Jetpack contest:

  • the first winner's code is absolutely not understandable to even an advanced XHTML+CSS developer. Reading Cc["@mozilla.org/appshell/window-mediator;1"].getService(Ci.nsIWindowMediator).getMostRecentWindow("navigator:browser"); in some code that is supposed to be simpler than XUL+chromeJS is puzzling, to say the least...
  • the second (and main) winner's code raises different issues: images are inline as data URLs because Jetpacks misses offline support and packaging; the HTML element inserted into the statusbar has to be precisely positioned and that will suck depending on the preferred user's font size; the color scheme names cannot be easily localized; I think closures are good and powerful but too many closures make code just unreadable and hardly maintainable; I am not sure I like jetpack.tabs.focused.raw.
  • The last winner's code is more readable and understandable but when I look at the "JetTabs" button it added to my statusbar on this beautiful Mac OS X screen, I can't help but think we're back fifteen years in time in terms of UI; some methods are poorly named, jetpack.tabs.open should probably be jetpacks.tabs.openNewTab because jetpack.tabs.open could open a URL into the currently selected tab.

If I look at the original Jetpack examples on the Labs' site, I also see plenty of things I dislike, things that must be discussed now or stick for a long long looooooong time.

So where are we now? First, we're far away from a Jetpack 0.1... It's in 0.6.2. So pretty advanced and already mature enough to attract developers even if it's not stable at all and could be drastically modified. What's Jetpack? It's an extensibility mechanism that has in my opinion two goals and two goals only:

  1. Extend the Mozilla add-on ecosystem, currently restricted to a XUL authoring elite, to Web developers,
  2. Pave the way for HTML5/JS/CSS as a universal and ubiquitous set of UI languages.

From my perspective, it's very clear that item 1 is not met at this time. Item 2 will require a different way of doing because if Mozilla moves alone along this path, extensions will remain Mozilla-only and it's then highly plausible Jetpack will remain Mozilla-only. Just like XUL. I don't think this is desirable. The W3C now works on interoperable Widgets and we see vast improvements in global Web interoperability. Why not in UI interoperability?

Whatever the beauty of the current Jetpack and the coolness of 50 lines of code adding a simple Exposé mode to Firefox, I think it's time, based on the initial Jetpack feedback, to think and act differently before reaching a point of no-return. Jetpack should remain a Mozilla Labs' thing, and there should be a joint effort between all browser vendors about browser extensibility. And, in my humble opinion, it should retain better the Keep-It-Simple-and-Stupid motto.

  • better, simpler, conceptually cleaner, more intuitive API ; no more imports or jetpack.me or wrappedJSObject.
  • localization, totally forgotten for the time being
  • availability of required external resources in offline mode AND/OR packaging of extensions
  • integration with native or native-alike (hear xul) UI and cross-platform issues, a major concern
  • security model not only of extensions' code but extensions' distribution, undiscussed at this time


1. On Thursday 7 January 2010, 12:04 by David

Sadly, I have to agree with you. The response to the extra resources question is even more depressing than the initial problem [1]. A python tool to build an XPI...

[1] https://wiki.mozilla.org/Labs/Jetpa...

2. On Thursday 7 January 2010, 12:10 by dafi

I agree with you at 99%, Jetpack programming model suffers from JQuery programming model, too much closures, too much anonymous/inner functions, IMHO.

When I moved to Jetpack world the first thing I disliked was the totally lack of localization APIs.
The lack of offline resources handling is a false problem for me, the data:// protocol is ever more used, many CSS libraries use it but I understand your point of view.

When an API exposes a "raw" object/function call it create a platform dependency but it allow to access to the "chrome" content and I want this is always possible

just my two cents

3. On Thursday 7 January 2010, 13:51 by Dao

You're missing an important goal: Jetpacks shouldn't break when random browser code changes, which means they need to be restricted to a tighter API that can be kept stable. I mention this because exposing .raw seems to break this. On the other hand, I think it's necessary to meet another goal: It should be possible to write most customizations as jetpacks rather than classic extensions. I think one of these goals will have to be dropped.

4. On Thursday 7 January 2010, 14:47 by Dominique De Vito

That's the first time I look at Jetpack code... and sadly, Jetpack learning curve looks like distant for web development learning curve.

Well, while Jetpack code is unfortunately still quite complex, programming may be easier through code generation from a statically typed language.
I have proposed with "GWT and Jetpack are going to shake up the web-based (RIA) desktop application landscape" - http://www.jroller.com/dmdevito/ent... - that Java-based GWT could be leveraged for Jetpack extension programming.

With GWT, you program with Java, but the Java code is compiled into JavaScript. Then, you benefit from Java language/environment/ecosystem (through static type/IDE/etc.) and you have at the end a HTML+JS program. With proper Java mock objects, or Java object encapsulation, Jetpack features could be exposed in Java, while some Jetpack programming difficulties may be hidden while programming in Java.

That's may be a good way to decrease Jetpack programming, and, also, to add Java programmers' community to the Mozilla extension developers' one.
But I would welcome any move to decrease inner Jetpack programming complexity.

5. On Thursday 7 January 2010, 15:57 by Laurentj

I agree with you.

Forcing to use HTML to create interface elements, whereas we have XUL, is just a return to the past. HTML sucks for interfaces, because of its box model.

Jetpack should allow us to use XUL !

An other issue of using HTML: we lost the use of the default skin of the browser. So, in many case, UI elements added by a jetpack extension just will breaks the appearance of the skin, or at least, just will be some horrible wart in the interface. They won't respect the plateform UI design etc...

6. On Thursday 7 January 2010, 17:06 by Wladimir Palant

I guess the idea for future user interface development is to standardize display:-moz-box along with -moz-box-align and similar to get the box model officially supported in HTML. At least that's something I've heard proposed a number of times, e.g. at the Developer Day 2007 in Paris. Unfortunately, specifying layout via CSS like this seems pretty complicated to me compared to the simplicity of XUL. Sure, separation of content and layout - but who cares for a 50 lines "extension"? Actually, do extension developers care at all? After all, most extensions (unlike websites) don't have a common layout for all of their dialogs. Separating the layout means more code but won't help you the least when you decide to change the layout later. All the common styles are located in the browser theme anyway.

The other problem I see with HTML-based UI is its flexibility, with HTML being primarily a language for documents. With XUL it is rather hard to do positioning wrong, the UI for all extensions looks decent and scales well unless the author tries really hard. But what will happen when people try to apply layouts from web page design to user interfaces (as they sure will)?

7. On Thursday 7 January 2010, 19:50 by gandalf

Hey Daniel!

Thanks for the feedback, I share a lot of your concerns, but I think that more that many of them are being worked on: https://wiki.mozilla.org/Labs/Jetpa...

In particular, since you raised the point, we're not going to leave jetpacks not localizable. We have a plan and I'm humbly working on it: https://wiki.mozilla.org/Labs/Jetpa... :)

I'll blog about it very soon, we're finishing a white paper on the technology we're going to use.

8. On Thursday 7 January 2010, 19:58 by Daniel Glazman

@gandalf: Zbigniew, I think you're underestimating my comments. I think Jetpack as it is is not the right solution for UI extensibility. Localizability is only one of the issues raised by the proposed solution but my concerns are deeper and more serious. Authoring XUL is apparently hard; if the new system is hard too and recreates yet another programming elite, time and energy was invested in vain. Furthermore, I'm a bit scared to see Mozilla work on this alone instead of trying to shape a formal (inside W3C for instance) or informal standardization group on UI extensibility.

9. On Friday 8 January 2010, 00:07 by Robert O'Callahan

If we were to pursue standardization of browser extensions, they would certainly end up using HTML plus possibly CSS flexbox. There's no way we'd get XUL standardized.

10. On Friday 8 January 2010, 00:45 by Pete

It's an open secret that mozilla tries to get rid of XUL asap. Jetpack is a first (helpless) step n this direction.

11. On Friday 8 January 2010, 00:51 by gandalf

@glazou: I'm just saying that there's much broader work going on than the current implementation suggests.

I understand your concerns, I even said that I share some of them. And I added that I'll try to make sure that localizability is well fit component for jetpacks.

12. On Friday 8 January 2010, 04:51 by drew

The goal of Jetpack is not to make the UI world adopt HTML 5. The goal of Jetpack is not to cater to the UI world in general. Depending on whom you ask, the goals of Jetpack are many and various.

When you have programming, you will have a programming elite. Some people will take the time to learn to program, some won't. No one leaves the womb knowing how to use Jetpack or any other platform. The barrier of entry to the Jetpack programming elite is much lower than the barrier of entry to the traditional extension programming elite.

The syntax of Jetpack is the syntax of HTML and JavaScript. If you really do not like the syntax of Jetpack, then you really do not like the syntax of HTML and JavaScript. If you do not like closures or functions, then you either do not like JavaScript or do not know how to use it effectively. In the former case, Jetpack can't help you.

"Simple" and "stupid" are words that mean various things, depending on whom you ask.

13. On Friday 8 January 2010, 09:56 by glazou

@drew: "When you have programming, you will have a programming elite."

Having a programming elite is not the problem here. Having a syntax that can ONLY create a programming elite is the problem.

"The barrier of entry to the Jetpack programming elite is much lower than the barrier of entry to the traditional extension programming elite."

Woooof. I think you should leave a bit the world of Mozillians and jQuery experts and ask more regular web authors.... I did.

"The syntax of Jetpack is the syntax of HTML and JavaScript."

It's the syntax of jQuery with a dash of pseudo-DOM hierarchy, and that dash is poorly designed.

Don't you see jetpack.menu.context.page.on("img").add() is conceptually wrong ?
Do you think });});}})); (taken from a real Jetpack example) is maintainable ?
Do you think jetpack.me is conceptually correct ?
Do you see the major problem with jetpack.selection ?

"If you do not like closures or functions, then you either do not like JavaScript or do not know how to use it effectively. In the former case, Jetpack can't help you."

You're on the verge of being insulting here. I suspect you take this too personally. By the way, I never said I dislike closures or don't use them. I said I dislike too many closures, in particular nested, because they make the code harder to read and maintain.

14. On Friday 8 January 2010, 10:21 by Pete

@draw: "If you do not like closures or functions, then you either do not like JavaScript..."
The advantage and disadvantage of javascript is the fact that you can use is in various ways. Some like prototyping, some don't. Some like the lack of strong typing, some don't. And the same goes for closures. There are a lot of people who are superb programmers but don't use closures and also a lot out there who even don't know what closures are. I assume that 90%+ of all web developers have no idea what closures are for.
Bottom line: Jetpack requires a specific way of programming which limits it's growth.

15. On Sunday 10 January 2010, 23:24 by Dan Brickley

Perhaps it's time for a more serious push towards x-browser extensions?

Whatever we have is going to have elements of uglyness to some eyes; at least if it was x-browser ugly, we'd only have to learn one such creature...

16. On Monday 11 January 2010, 13:41 by mcepl


I have written 1700 wc-l lines of code jetpack (http://mcepl.fedorapeople.org/scrip... it was originally a Greasemonkey script), so let me speak from a bit of personal experience:

I. That bit of jQuery

This was my first experience with jQuery and initially I wrote whole script using jQuery objects almost exclusively. I found this implementation of jQuery to be pure disaster ... tons of things didn't work, jetpack was bouncing to the membranes all the time, and I had to replace some constructs with native Javascript to make it work at all. When doing that I was thinking hard about some of benfits provided by Javascript and begun to doubt it as well. What's so better on

a = $("#myid", this.doc);

comparing to

a = this.dok.getElementById("myid);

Especially when I have a decent text editor which has word-completion (and some kind of text completion is I believe in any text editor better than Notepad) I don't see any gains in jQuery syntax. Given that jetpack requires FF 3.5+ anyway, whatever more complicated jQuery constructs could be replaced with querySelector API, which is better standardized (I thought originally that jQuery selectors ARE CSS3 ones, as I found later they aren't; #fail). Together with Array.map & co. methods, and not mentioning Python-style generators, I think plain Javascript could be as nice and maintainable as jQuery code, so I am not sure what exactly jQuery brings us.

Moreover, then I took a look inside of jquery implementation as provided in jetpack and I was appaled. Tons and tons of code and object for things which could be written by couple of lines of plain Javascript code!

In the end, I have now exorcized all jQuery from my script and everything works much better now (even some plain Javascript constructs which were mysteriously not working before, started to work suddenly, even though I could not find any connection to jQuery anywhere around them). I don't think I've got into full-size comp.lang.javascript anit-jQuery religion, but I don't see much of its value in FF3.5+-only environment (it might have place for cross-browser development).

II. General Javascript and Jetpack as a library

Actually, the advantage I've got from jQuery experiment was that it forced me to think about Javascript more in terms of functional programming. By doing that, I found that actually tons of my for (var i = 0, ii= arr.length; i<ii; i++) cycles are totally wrong. So, instead of complaining about closures and map/reduce style, I have to say thank you for showing me The Light.

Otherwsie, yes, Jetpack is horribly incomplete, and the library structure is confusing ... jetpack.settings.open() (which doesn't work BTW) which stores stuff in jetpack.storage.settings.foo makes me wonder. Using unnamespaced variable manifest for setting important values to the script seems crazy to me, etc.

Moreover, if we want to make this hacking tool for everybody, then the crucial ability is to load external javascript libraries easily. Currently ones has to try inject script element and it works only when the Mooon is in the right state. Oh well.

17. On Monday 11 January 2010, 13:51 by mcepl

And yes, @dafi is right, not having any local data sucks. Jetpack should provide some packaging into something like .xpi. I am now downloading some JSONs with static data only because I found it more simple than trying to include them locally.

18. On Thursday 14 January 2010, 09:54 by uggs outlet
<Daniel> spam removed but not deleted to preserve comments' hyperlinks</Daniel>
19. On Monday 18 January 2010, 18:50 by Daniel Buchner

Hello All,

I just wanted to let you all know that the current Jetpack platform is an experiment. About 3 months ago we made the decision to proceed with what is essentially a rebooted, rewritten production version of Jetpack.

This new version of Jetpack will solve many of the issues you all mentioned. Along with the new rebooted Jetpack, we will be releasing an SDK application that will make building and publishing a jetpack as easy as pushing a button - there is no python packager to run, you won't even have to touch the physical files on your machine, just code and go.

To the point of the type of programming Jetpack "forces" on developers, I hear you loud and clear. I am a Mootools man myself, and I can assure you, one of my highest priorities is to make it possible for any developer to choose any js library they would like. Developer choice is important and we will not be mandating a specific js library or code abstraction over another, as with any web page, you will have the options you have come to expect.

This will all take time, security concerns and the nuances of a browser's chrome javascript environment require us to reboot this platform with the utmost attention to code quality and architectural design.

In the coming months your concerns will be satisfied, Jetpack was an experimental prototype hinting at what could be, we are now developing the platform that is the realization of what we learned in that experiment.

Thank you all for your feedback. As always, we are passionately dedicated to providing developers with an extension development platform that serves their needs; I can confidently say that very soon, Jetpack will do just that.


Daniel Buchner
Jetpack Product Manager

20. On Tuesday 19 January 2010, 09:34 by Fabrice


Thanks for your comment !

Your say that "This will all take time, security concerns and the nuances of a browser's chrome javascript environment require us to reboot this platform with the utmost attention to code quality and architectural design."

However currently the code for jetpack reboot available (http://hg.mozilla.org/users/avarma_... and http://hg.mozilla.org/users/avarma_...) doesn't seem to follow the same rules as the rest of the mozilla platform : no way to follow a feature implementation from a bug number, and apparently no code review.

This, combined with a lack of communication (a black box effect) has been a great part of the current controversy about jet pack and other labs efforts in my opinion.