For Browser Extensions, Grease is the Word

Chrome now has Greasemonkey support. The Chromium patch came from Aaron Boodman, who is at once a Google employee and the brains behind the original Firefox Greasemonkey extension.

It makes me wonder if this is the plan for Chrome add-ons. Forget about anything like Firefox’s add-on mechanism and just rely on Greasemonkey. With the right APIs, it’s all you need.

For a long time, I have been confused and disturbed by the disparity between Greasemonkey and Firefox extensions. Creating a Greasemonkey extension is dead simple for any Ajax developer; creating a bona fide Firefox extension is more complicated, and involves writing the kind of meta-descriptions and JARs that most Ajax folk avoid. (The kind of simplicity mantra that has made JQuery king of the hill for now.)

You might recall I automagically ported the domain teleporter Greasemonkey script to a Firefox extension a while back. That this was possible, and easy, demonstrates that the Firefox extension mechanism could be made a lot simpler. I thought there was talk of doing it for FF3, but it didn’t happen.

What do Firefox extensions do that Greasemonkey can’t? Nothing Greasemonkey can’t get around.

  • Extended access – manipulating the Browser Object Model, accessing local file system, etc. All of this could be possible from a Greasemonkey script with the right APIs available. There are security implications, of course, but as long as users are aware of who can do what, it’s no different from what we have now. It may be even better, due to Greasemonkey’s built-in wildcard-based URL filtering, so that certain apps might only be limited to certain domains.
  • Metadata – certain metadata is present in an extension. This could just as easily be part of Greasemonkey’s metadata.

It’s my hope that Google’s vision for Chrome plugins is Greasemonkey on Steroids, and that this unleashes a whole new ecosystem of powerful add-ons that have until now required too much effort to build.

6 thoughts on For Browser Extensions, Grease is the Word

  1. XPI is overkill for lots of things, and it has lots of room for simplification… but a) there are good extensions that do not target loaded documents but the chome itself b) there are good extensions that are document-oriented, but require a level of complexity that hardly makes sense to pack inside a single script file (or that even uses native code)

    Out-of-the-box userscript support is a huge step towards empowering users to shape the web, but doesn’t do much towards what I perceive as google’s vision of the browser-is-the-os.

  2. Xavier, I believe (a) can be overcome simply by giving scripters the APIs to talk to the chrome. And wrt (b), I would rather have an architecture that starts small and extends upward than start with the giant beast (ok I’m exaggerating) and make it overkill for the multitude of simple apps. Even with the current Greasemonkey technology, you can write a complex app by simply pulling down extra code using On-Demand Javascript. An enhanced version of Greasemonkey might let you declare dependencies, which would automatically download. The main point is, whether 1 file or 100, it’s all just plain old Javascript.

  3. Pingback: Ajaxian » Greasemonkey, Chrome Edition

  4. Pingback: » Blog Archive » Greasemonkey, Chrome Edition

  5. Pingback: » Mozilla Bespin Meetup FND’s Blag: Just Another Personal Wobsite

Leave a Reply