Mozilla and Google Announce HTML-Based Extensions

It appears that great minds think alike (or in the case of open-source software and the close-ties between Google and Mozilla, share-alike). Within a week of each other both Mozilla and Google have announced new initiatives to allow for extensions to their browsers to be written using regular HTML / JavaScript and CSS, greatly lowering the bar for developers to join in. Strap on your Mozilla Jetpack and take a peek at extensions for Chrome.

Of Jetpack:

Mozilla Jetpack is a Firefox extension itself, which then provides the framework necessary to develop HTML-based Firefox extensions. The big improvement? Not having to restart the browser to install or update extensions! The downside is that Mozilla are effectively creating an extension system within an extension system. Joy. That could bring all sorts of headaches trying to manage a dual-layer extension system, let alone communicating that to end-users. However–that said–it’s very unlikely Mozilla intend it to be this way, rather they may bake Jetpack into Firefox itself, and remove that extra layer of complication.

By creating Jetpack as Firefox extension they do not have to wait until the next release of Firefox to make the functionality available, especially if it’s new, untested and requiring feedback. Web developers will have no problem installing an extension and working with the platform in view that when it does go 1.0, Mozilla will have had all the feedback they need from developers to ensure a smooth delivery to regular users.

Of Chrome

Chrome has not had any extension ability just yet, and it’s often requested. If only for AdBlock sometimes.

With Chrome’s design throwing away so much UI to begin with, it could seem counter-intuitive to provide a way for people to just add it back in. Ultimately that way allows Google to avoid adding something for everybody, and instead let the community provide the extensions. It worked for Firefox, why not Chrome?

Of Ease

Writing a Firefox extension is difficult. Really, really difficult. Not in the comp-sci kind of way, but simply in the difficulty-through-unfairness kind of way. Much of the XUL language is simply undocumented, or badly documented with many sections being out of date or outright missing features that are available. The JavaScript API is a mess requiring very heavy JS to do even simple things–JavaScript which you would have no hope in the world of actually learning without disassembling other people’s extensions. If you want to do something simple–show only folders in a tree view of files, for example–it is usually a long Google search and disassembly mission finding the answer, because the documentation certainly doesn’t help.

Whilst I welcome Jetpack and may very well have a go at it, it is still just another layer on top of the real XUL code underneath. Jetpack may be good if you want to add UI, but no good if you want to remove it or do any major reshuffling. Jetpack may require that when you get to a certain level there will be something you want to do that will only be possible by moving to a full XUL extension. Though, that may not necessarily be a bad thing–it makes for a natural progression path for improving developer skills.

Of Importance

This is really very important to us. It gives us a certain democratisation of one of the pieces of software we interact with daily. By lowering the barrier for developers to invent extensions, it increases the ability for people to remix and shake-up the browser just as much as the pages we use to view it. Imagine extensions that deeply interact with the webpages themselves, sharing various code elements between the two. In a far-flung future we may finally be reducing the browser to the thinnest of veneers as web pages become apps themselves. 😉

Of course, the lower the barrier, the more crud that spills over. But now, instead of being forced to look at a terrible web page, we can just choose to not install it.