As a result of Mike Connor’s post, there’s lots of discussion about extensions, theming, Personas and Jetpack. This is my livelihood, so I definitely have to jump in.
First, let’s talk about Personas. I hate to burst everyone’s bubble, but:
Personas is not lightweight theming. Personas is wallpaper.
We’ve had it since Windows 3.0 (may be even before). It’s pretty wallpaper, but it’s still wallpaper.
Lightweight theming is a different beast. Lightweight theming is the ability to theme the browser window WITHOUT theming the rest of the browser. So lightweight theming might involve changing things like browser background images (more than one), toolbar buttons, and possibly the URL bar or the tabs. I’ll be a little self serving and say that everything Brand Thunder does is lightweight theming. You can see examples at the gallery.
Personas is not a suitable replacement for Firefox theming. It doesn’t even come close. And looking at the designs for future versions of Firefox, Personas becomes irrelevant – there’s very little browser chrome to even see the background images. (Clue to Firefox developers – make the new tab window transparent like Chrome).
People point to Personas and say “look how popular it is – people must want theming that way.”
Personas’ success is about marketing.
Personas is the only extension that Mozilla markets. They market it on first run pages, download pages and home pages. It has a dedicated domain. It has special privileges for being installed without the add-on security warning. It was a recommended add-on from day one. They even have a custom bundle of Firefox that includes Personas!
So please don’t tell me that Personas is the future. Personas is the present. Clearly a completely new solution will be needed for future Firefox versions.
Now let’s talk about Jetpack.
Jetpack is like giving me an Erector set when I used to have a Home Depot.
Let’s look at the problems that Jetpack attempts to solve and see if a new programming model was necessary to solve them.
Install without restart -
If extension developers were given a specific set of APIs that they could use that didn’t require restart, then extensions could be marked as “doesn’t need restart” and this problem would be solved. All Jetpack does is pre-grab parts of the Firefox UI so that when things are placed there, Jetpack handles their placement, not Firefox. This could be done with any extension API. It doesn’t require Jetpack.
Ease of creation -
A learning curve is a learning curve. I don’t know jQuery, so Jetpack has a learning curve for me. Jetpack is simply trading one programming model for another. I’ve been to presentations where HTML developers were shown how extensions work and within one hour they could create extensions. Doing very interesting things with extensions might be difficult to learn, but that’s why you create an API. And that API does NOT have to be Jetpack specific. Packaging can be a little tricky, but again solvable outside of the context of Jetpack.
API -
If the extension API isn’t very user friendly, fix it. Isn’t that what FUEL was trying to accomplish? If you want a stable API that doesn’t change from release to release, create one. There’s no need this API needs to be created as a part of Jetpack.
Forward compatibility -
Extensions break from release to release of Firefox. That’s just a fact of life. The only way to prevent this is to give extension developers a very tiny sandbox in which to play. We don’t want this. Give us a big sandbox and if we break, we break.
The problem is not that you break us. The problem is short release cycles
Right now, the Firefox team is aiming for six month release cycles. For an extension developer, the last two months of that cycle are when we can really start checking out things and it’s only in the last month that we can actually release addons that have the correct version in install.rdf (due to AMO restrictions.). Most extension developers have multiple extensions and probably a day job. Updating five or 10 or even hundreds of extensions can be quite problematic.
Jetpack simply creates a new set of problems and a new context to solve those problems. We should try to fix those problems in the existing context.
I think the core problem here is a disconnect between Mozilla Labs and the rest of the Mozilla community. Mozilla Labs operates in a very closed community, completely contrary to the way other Mozilla projects are done (at least for the initial phases of a project). I think that contributes to their myopic vision of the future of the browser. I’d much rather see Mozilla Labs work with the community to propose ideas and foster those ideas to create a real open source lab versus coming up with ideas and then trying to force those ideas on me.
And incidentally, Internet Explorer is a great example of what happens when you give people a limited set of APIs to work with. They come up with elaborate hacks in order to make things work. And those definitely break from release to release. If you limit people, they will come up with ways around those limits. Please don’t limit me.
