Removing obstacles for extension developers is my group’s primary task at Mozilla. There are lots of ways we can do this and areas include documentation, tutorials, samples and tools. One thing that becomes clear after watching and helping extension developers is the difficulty some have getting familiar with the Mozilla framework and the plethora of object and interfaces available. Not only are some of the concepts foreign, but in many cases there are no clear ways for extension developers to achieve their goals. There are places to get help. The Mozilla’s IRC channels are a great place to ask questions, especially #extdev.
We have also started work on a JavaScript library to help extension developers shorten the learning curve, feel more comfortable and generally be more productive. Codenamed FUEL, the library is primarily a wrapper around commonly used parts of the Mozilla framework which are unfamiliar or complicated. Some of the goals are:
- Make it easy for developers to do common extension tasks.
- Use terminology and interfaces familiar JavaScript developers.
- Hide as many implementation details as possible.
- Allow developers to get access to underlying XPCOM interfaces if they want to.
- Act as a buffer between extensions and Firefox internals.
In addition to making it easier for extension developers, we also want to help improve the overall quality of Firefox. A broken extension appears to be a broken Firefox. Anything that can be done to help extensions avoid breakage and use clearly defined methods of hooking into the browser will help.
Currently, we (myself and John Resig) are in the planning and prototype phases. John’s JavaScript library experience (jQuery) is a huge plus for us. It’s great to have him working at Mozilla.
I invite you to take a look at the FUEL wiki pages and send us feedback and comments. You can use the discussion pages on the wiki or visit IRC (we hang out there way to much) or even use the newsgroup thread.
Update: I forgot to mention that our goal is to ship this library with Firefox (and other Mozilla applications as needed). Of course, we would also want it be able to usable in older Firefox releases too. Packaging could be a challenge.
Will this library be included with a user’s firefox extension in the future?
We do want to ship the library with Firefox – I updated the post.
The name is nice, but as an acronym it is not very forward looking. I could see this being a useful library/framework for Thunderbird or XULRunner as well.
Is there any overlap with jsLib.mozdev.org?
I’ve always wished jsLib was included with mozilla stuff. Maybe similar functionality will find its way into XULRunner…
Name shmame. Point taken but that’s beside the point.
This is sensational news. I’m so incredibly happy that Mozilla has you guys to tag team on behalf of the likes of new extension devs like me.
I took a look at the code snippets for file i/o yesterday and, not being a C dev, I was intimidated. Anything that makes this less intimidating and moer efficient in operatino and learning terms, is sensational.
Looks ‘un like Ize gots me sum IRCing to do 🙂
Why not release a Firefox 1.5.0.x update with this bundled (or perhaps release 1.5.1.0 to show the changing of API compatibility).
I’d also like to know how this affects/overlaps jsLib (which I’ve also always thought should be included in Firefox/XULRunner. I also remember people having issues where multiple extension developers had used jsLib, and sometimes their extensions would conflict due to something shared – better make doubly sure this doesn’t happen with FUEL 🙂
Why is this considered to be a separate framework with it’s own name? Any simplication/refactoring/ease-of-use improvements to the Mozilla API should be considered as incremental patches to the existing Mozilla code base.
I hope this framework will include more Array and Object-handling goodies like what Prototype does (look at all those especially useful Enumerable methods). jQuery’s $() is a good plus, imagine something like $(‘listbox listitem listcell’).
Hi Mark,
I am just starting researching how to present our approx. 5,000 xml formatted articles online. I see that we could have a stack with XUL + CSS + Xquery + eXist. But haven’t found examples of this being done; specifically, how to use XPCOM to make the XUL front-end communicate with a remote (or local) eXist DB. Is FUEL relevant to this?
Michael