If you’re ever spent time trying to grok Firefox Extension development (especially if you’re coming from a pure web development background). You’ll find that there’s a lot that you have to learn to get up to speed. To name a few: XPCOM, RDF, XUL, and XBL in addition to a huge number of custom APIs for the different aspects of Firefox (Bookmarks, File I/O, Adding Buttons, Menus).
My first major project at Mozilla is to work with Mark Finkle and develop a JavaScript Library for use by Extension developers. If you’re very new to extension development, then this will help you out, completely. We extrapolate out all the complex concepts into one, simple, package. The best part is that this whole thing is going to be available in the whole Mozilla platform (Firefox, Thunderbird, Seamonkey, XULRunner); and in multiple versions (for example FF 1.5-3.0).
We use very little of the actual underlying terminology and naming conventions present in the existing code base (this is bound to irk most established developers), and instead have adopted much of the terminology already present in JavaScript/DOM development. You can see evidence of this in our early API planning for versions 0.1 (Plan) and 0.2 (Plan).
In a nutshell, for 0.1, here’s what we’re tackling: Preferences, Events, Observers, Extensions, Toolbars, and Buttons; and the kind of improvement that you can expect:
Accessing a Boolean Preference
// 'Old' XPCOM way
var prefValue = false;
try {
prefValue = gPrefService.getBoolPref(this.domain);
} catch (e) {
}
// 'New' FUEL way
var prefValue = Preferences.get(this.domain, false);
Watching for a change in a preference (obvserver).
// "Old" XPCOM way
gPrefService
.QueryInterface(Components.interfaces.nsIPrefBranch2)
.addObserver(this.promptDomain, this, false);
// "New" FUEL way
Preferences.addEvent( this.promptDomain, this );
Setting a unicode preference.
// "Old" XPCOM way
try {
var str = Components.classes["@mozilla.org/supports-string;1"]
.createInstance(Components.interfaces.nsISupportsString);
str.data = aURL;
gPrefService.setComplexValue("browser.startup.homepage",
Components.interfaces.nsISupportsString, str);
} catch (ex) {
dump("Failed to set the home page.\n"+ex+"\n");
}
// "New" FUEL way
Preferences.set("browser.startup.homepage", aURL);
We’re really excited about where this is going, and we’d love some feedback. Feel free to comment on the wiki, find us on irc, or drop us an email. Here’s Mark’s take on the project. I’m really excited to be working with him and the whole developer relations team.
Arrix (January 9, 2007 at 11:00 pm)
Great! This fills the gap between pure web development and extension development. Wishing to see jQuery style in FUEL.
pd (January 10, 2007 at 12:57 am)
I’m feeling a lot of love coming from you guys :) LOL
Can’t wait to have this available. It will be somewhat painful but useful for me to learn the olden way now on my current project, but when yours is available it will be superb.
The Finkle/Resig tag team rocks!
Best thing Mozilla has done in a long time.
John Silvestri (January 10, 2007 at 1:52 am)
Correct me if I’m wrong, but my reading of the last example is incorrectly titled. It certainly looks like “Retreiving a unicode preference” should say “Setting a unicode preference.”
You’ll be pleased to know that I readily caught this based on how readable your FUEL code is. ;) If I can’t infer that “Preferences.set” doesn’t mean ‘retrieve,’ then I really don’t deserve my CS degree. ;)
Looks like a great project!
Brendan Eich (January 10, 2007 at 2:02 am)
Hey John,
Great to see FUEL (and you on board at Mozilla — I saw your jQuery talk at the Ajax Experience in Boston but didn’t get to say hello in person, but soon enough you’re working for us — remind me to give Shaver a bonus ;-). This is more like what I was aiming at back in the old days with JavaScript. After Netscape 2 and 3, the DOM became a large set of specs hacked over by numerous w3 members, with Netscape and Microsoft in the lead. It was stretched to work for servers as well as browsers, or perhaps at the expense of browsers. The results were mixed, and the concern for making common tasks simple was lost.
The same problem (too many cooks, too many audiences, and too much intermixed specialization) afflicts Mozilla’s APIs, but JS libraries are already helping. My hope is that we can nativize FUEL in some future (Mozilla 2) where it pays off to do so, and remove many of the underlying, over-complicated APIs that FUEL veneers. Or at least replace them with better-layered, more progressively complex sets of APIs. Anyway, looks like you guys are off to a great start.
/be
John Resig (January 10, 2007 at 2:30 am)
@Arrix: “jQuery” in FUEL may not be too far off. To start with, we’re simply bundling “concepts” (Bookmarks, for example). It’s logical, however, that in order to build good concept libraries that the underlying core be solid. Thankfully, since Firefox already supports good technologies like XPath, this is going to be very non-painful – and quite possible.
@pd: Thanks a lot for the encouragement – we appreciate it!
@John: Yes, that is supposed to be “Setting”, fixed – and thanks!
@Brendan: Great to see you stop by! I’m already having a blast here at Mozilla, and I’m barely a week in. It’s an interesting point that you made about all the “lower”-level APIs being fairly well established at this point – even things like DOM. Since those concepts have solidified, the number of libraries has really exploded; which is interesting unto itself.
I suspect that FUEL will be a moving target for a little bit, as we try to hammer down the core concepts that we want it to embody. However, I’m really excited about this project too – there’s a great potential for some great advances to be made.
Dao (January 10, 2007 at 9:01 am)
Why calling something addEvent when it’s actually an observer? Btw, addEvent isn’t a good name anyway, because you’re really adding a listener for an event. That’s not too important for a freely available function, but since this a bit more “official” (could even ship with Firefox 3, couldn’t it?), I think the API should be as consistent as possible with existing DOM & Co. interfaces. Nevertheless, great stuff!
Nathar Leichoz (January 10, 2007 at 10:46 pm)
Will this library be included with Firefox builds? Because I think Firefox’s own widget toolkit would benefit from this library. If not for the simplicity then for the reduction in code size.