Firefox vs. Chrome SDKs

I wrote an extension for Firefox and Chrome. Here’s what happened:

TL;DR; The Chrome SDK felt simpler with clearer documentation. The Firefox’s developer community is incredibly helpful and their review process will make you a better programmer. You can’t go wrong with either one – but the Chrome SDK will get you there faster.

First Impressions:
I wrote the Firefox extension first because I use Firefox. I downloaded the SDK and followed the introductory tutorial. After the intro, there are some good tutorials on how to structure the extension and how to do specific tasks like detecting a webpage load. I then learned that there are high-level API calls and low-level API calls.

Feasibility Study:
While the high-level APIs are well-documented, many low-level APIs are marked as “unstable” or “deprecated”. This was unnerving when I found out that I needed to use an unstable API to achieve core functionality for my extension.

Eventually, with sufficient searching, asking questions on the Mozilla Developer IRC channels, and testing out code examples, I was able to get the basics working. There are some incredibly kind and gracious developers in the Mozilla developer network. I would not have gotten very far without their help.

Basic Functionality:
I needed to let users manage a list of websites, and update the plugin’s behavior whenever the list was saved. In Firefox, content modules don’t have direct access to storage. This means that instead of just saving the list whenever the user presses the Save button, we have to write some message-passing code to pass the list to the main module, which then saves it.

Plugin Options:
Firefox lets us create Preferences for extensions, which can be accessed by opening up the browser’s Add-ons window (Tools; Add-ons). The way to do this by specifying the preferences, their data-types, as well as some other basic info in the extensions’ manifest file. Then, in the extension’s main module, we can handle changes to the preferences through a listener. This means that Firefox stores and treats preferences separately from other data stored by the extension.

In my case, changing preferences also affected the content module, so this meant writing some more message-passing code. By the end though, the extension worked just as I’d wanted it to.

The Chrome SDK:
Once I released the Firefox version, many of my friends asked for a Chrome extension as well. I was pleasantly surprised that the Chrome SDK is more straight-forward. The Chrome extension, which has the exact same functionality as the Firefox extension resulted in less code, clearer and more consistent modules than my Firefox extension. Here’s what they did right:

  • Just one API: no separate High-level and low-level APIs. It felt clearer – in-fact, it was so good that I never had to turn to the chat-rooms for help.
  • One storage for all things: There is no special data storage for preferences. This means you only have to deal with one data-store for everything.
  • Open-ended Preferences: In Chrome, the preferences screen is free-form: just another HTML document. Put whatever you want in it, and save the user’s input directly into the extensions’ data store.
  • Consistency across modules: Since all modules have access to the data store, there is no need for special message passing code! This cleaned up my code by quite a bit and essentially standardized the basic structure of all modules.

Just like the Chrome section of this article, I had to write about half as much code for the Chrome extension, once I slogged through all the learning and writing of the Firefox extension :).

Leave a Reply

Your email address will not be published. Required fields are marked *