Chrome is catching up to Firefox pretty quickly in the extension department. The Chrome Extension Gallery has added more than 2,700 extensions in just a few months. Meanwhile the Mozilla team is busy perfecting Jetpack to make life much easier for add-on developers. With the 0.8 release out the door, let's look at what the road ahead looks like for Mozilla Jetpack and the future of add-ons with Mozilla.
Jetpack 0.8 marks the end of prototyping for the project. As Jetpack matures, it’s going to be an important tool for Firefox to maintain its market share in the face of Google Chrome
It certainly has worked for Chrome. Google doesn’t use Jetpack, but the extension system for Chrome doesn’t require a lot of Chrome-specific knowledge for developers, and thus the Chrome add-on ecosystem has flourished in the very short time since Google pushed extensions out into the Chrome browser.
As a side bonus, Jetpacks will allow users to install add-ons without the need to reboot the browser.
What’s new in 0.8?
Jetpack has been iterating pretty rapidly. The 0.8 release brings a few new APIs to work with. Namely, a toolbar API and the Places API to work with history and bookmarks in Firefox.
Places will allow Jetpacks to search bookmarks and history and also manipulate (add, edit, remove, tag) bookmarks. This is an important feature to provide, since bookmarking is a pretty important part of what goes on in the browser. Don’t believe me? Check out data from Mozilla’s Test Pilot study of a day in the life of a browser.
The Toolbar API lets a Jetpack place a button in the Firefox UI and add functionality to it. This should allow adding, modifying and removing items from the navigation toolbar and bookmark toolbar.
Roadmap for Jetpack
A full list of all of the Jetpack extension proposals is available on the wiki, and there’s also a roadmap of the Jetpack roll-out for developers.
The next stage of development is going to involve a reboot of the project. This means that some things are going to be changing, and the project is going to be focusing on some new issues that weren’t originally in focus: Namely extensibility and security.
Security is the biggie for me. The Mozilla project had a scare recently with suspected malware in experimental add-ons in the repository. It turns out that it some malware did make it through to users, though affected downloads were less than 700. But it highlights the potential issues with add-ons passing malware to the browser or creating a security issue of some kind.
And security was not at the forefront when Jetpack was introduced. Atul Varma writes about the state of security in Jetpack, and says that the team found the original model had a number of vulnerabilities. Code review doesn’t scale well when you lower the bar for development, especially when the bar is lowered to include developers who aren’t necessarily schooled in security.
So, expect to see a lot of changes in Jetpack as it reboots. The reboot release is currently set for March 1. Items on the long-term roadmap include a Panel API for Jetpacks to include a floating window or “panel” in the UI, storage for Jetpacks, and interaction with Tabs.
Note that I don’t think for a minute that this spells the end of standard Firefox extensions. I think there will always be a place for extensions that work more deeply with the browser, but long-term Jetpack is probably going to be the future for more lightweight add-ons that don’t need to get deep into the bowels of the browser.
A United Add-on Format?
While Mozilla is rebooting Jetpack, Google Chrome is speeding along with its extension ecosystem. Extensions were only officially announced in November, but the Chrome Extension Gallery is chock full of extensions for Chrome already. More than 2,700 extensions have been added in less than three months.
Given the rapid uptake for Chrome by users and developers, the Firefox folks have their work cut out for them to catch up with Chrome in ease of development.
What isn’t on the Jetpack roadmap, but that I’d really like to see is a united format for Jetpacks and Google Chrome extensions. As a user, I like being able to choose between Firefox and Chrome, and not just because I write about the technologies. Each browser has its strengths and weaknesses, and I like being able to switch back and forth between the two.
For developers, though, maintaining two add-ons has to be a headache. Extensions aren’t just about extending the browser anymore, they’re pretty much an extension of a lot of Web sites. Take a look at services like Evernote, which depend (at least in part) on extensions in the browser. These days there’s less of a headache getting sites to display and work properly with the popular browsers, but the pain has moved to extensions.
It’s not just Firefox and Chrome, either. There’s Seamonkey, which will presumably support Jetpacks at some point, and then all of the other WebKit and Mozilla-based browsers. It’d be outstanding if developers could write one extension to support the whole lot.
To some extent that’s already possible. While Firefox Add-ons have too much Firefox-specific code to easily port to Chrome extensions, Jetpacks should have no such baggage. In fact, some have done it already and outlined the differences between a Jetpack and Google extension. The Jetpack folks might want to take a look at the differences and see about harmonizing a bit with Chrome extensions.
In the meantime, it’s good to see Jetpack speeding along. Lowering the bar to producing extensions has worked out quite well for Chrome, and having Jetpack in mainline Firefox should be really good news for users and developers.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62