Add-ons: To SDK Or Not To SDK
Myk Melez’s recent post on the Jetpack project 2011 roadmap is timely. Firefox 4 final is approaching fast. Quite a decent percentage of add-on authors have updated their add-on already. For those who have not, I imagine some are wondering whether they should migrate from the traditional XUL add-on approach to using the SDK. It’s worth noting that there are already many SDK add-ons out in the wild, most conceived as new ideas.
Myk’s post is long but well worth reading fully. However, I want to hone in on this part related to why the SDK is not good for updating traditional add-ons:
First, but definitely not foremost, the SDK is still in beta, which
means it is not yet at a level of quality and functionality that is
appropriate for many developers.
More importantly, the SDK delivers not just Firefox 4 compatibility but
also, and primarily, a new way of building add-ons, and that means that
using it to upgrade a traditional add-on means rewriting the add-on to a
significant degree (at least the parts that touch the Firefox user
interface). And that’s a lot more work than it would take to make the
minimal changes necessary to make that add-on compatible with the
changes to Firefox 4’s user interface.
The latter is talked about in more detail. Of course, there are always exceptions and those that come to mind for me are add-ons that use the Greasemonkey compiler to build an extension based on a user script that provides functionality for a particular site. The page-mod module in the SDK is a good alternative for this.
At Briks we’ve been using the SDK recently, for fun projects and for client work. We’ve been using the cfx driven command line tool, which is solid and easy to use. The last time I checked the Builder was broken (but it is getting more solid by the day). We’ve been updating other traditional add-ons for Firefox 4 and David and I recently had this conversation (paraphrased):
Brian: Stepping back, what is the win from using the SDK?
David: forwards compatibility?
David: easier maintenance?
Brian: I’m not convinced of either, because this is such a XUL/overlay heavy add-on
David: yeah me too. hence the question marks :)
Brian: unless at some stage in the future it loses a lot of XUL, but I doubt that will happen because …
Brian: if https://jetpack.mozillalabs.com/sdk/1.0b1/docs/#guide/xul-extensions works, we could have our cake and eat it
Brian: i.e. use the SDK for packaging, but update the code as we like isolated in a directory inside
Brian: maybe we should try that with the exisiting code as an experiment
Brian: and hack install.rdf to support 3.6 and try it there first
David: 1 sec
David: just reading up on that.
David: could try with a test addon
David: i’m not sure of the advantage of just using the sdk to package?
Brian: me neither
Brian: Ok, lets ditch it
So to summarise:
- If it ain’t broke, don’t fix it. If you have a XUL based add-on take the path to least resistance and get it ready for Firefox 4. The chances are you won’t get some of the things you are looking for, such as no restart.
- If you have a user-script driven add-on, or a XUL-less Web focused add-on, consider the switch.
- If you are starting something new, try the SDK first.
- The SDK is still in beta, beware of rough edges but at the same time try to play a role in making it stable and moving it forward (see Myk’s post).