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:
- Extend the Mozilla add-on ecosystem, currently restricted to a XUL authoring elite, to Web developers,
- 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