Why I’m enthusiastic about the Add-on SDK

Why browser development is hard (and what we can do about it)

It should hardly come as a surprise to anyone when I tell you that browser development is hard.

Most browser code is written in C++. This is problematic for a number of reasons. First of all, C++ code takes a long time to compile. Compiling Firefox from scratch can easily take up to 15 minutes or more, even on a high-end system. This makes it very hard to quickly write and test something. On top of that, C++ code is error prone and hard to maintain.

Another problem is that as a project becomes older, it accumulates ‘cruft': design decisions which seemed like a good idea at the time but have proven to cause more problems than they solve, interfaces that were bypassed in order to gain a bit more performance, quick hacks that were added under deadline pressure etc.

In practice, the accumulation of cruft is impossible to avoid, and once it is there, it is nearly impossible to get rid of it, because other code has come to depend on it. As a result, cruft becomes an increasingly large burden as a project gets older. This is especially problematic when dealing with C++ code, for the reasons I mentioned earlier.

Since Gecko is an older project than WebKit, the problems it has due to cruft are correspondingly larger as well. Although WebKit is slowly starting to run into the same problems as we are, this makes it very hard for us to keep up. That we are able to do so at all is a testament to the the passion and skill of our contributors.

Having said that, the burden of cruft is not going away, and is only going to get worse over time, so we need a strategy to deal with it. The most obvious solution is to find more contributors. However, C++ has a high barrier of entry, making such contributors hard to find.

A better solution, which in my opinion we should be moving towards, is to keep only the performance critical code in C++, and move as much platform code as we can from C++ to JavaScript. Having less code in C++ will lead to reduced compilation times. On top of that, JavaScript is less error prone and easier to maintain, which will alleviate the burden caused by cruft.

How the Add-on SDK can help

To move platform code from C++ to JavaScript, JavaScript code needs to be able to call into C++ code. Within Gecko, we use two technologies to accomplish this: XPCOM and XPConnect. XPCOM is a component framework that allows you to write components in a language agnostic way, and XPConnect is a reflection layer that allows you to use components written in one language from the other language.

The problem with XPConnect is that it is cumbersome to use. It has a verbose API, and since XPCOM components are language agnostic, their interface can not use idioms that are common in JavaScript code, but not in C++ code, such as higher-order functions.

Because XPConnect is so painful to use, many add-on developers have written their own abstraction layer on top of it, in order to smooth over some of XPConnects rough edges, and to provide an API that feels more native to
JavaScript.

Unfortunately, almost every add-on developer write his own abstraction, so that almost every add-on reinvents the wheel in one way or another. Whenever something like that happens, its a sign that the API you are providing does not meet the needs of its users.

It’s from this observation that the idea for the Add-on SDK was born: the goal of the SDK is to provide a set of high-level platform APIs that feel native to JavaScript and are easy to use, on top of low-level APIs such as
XPConnect.

Originally, the Add-on SDK was primarily geared towards add-ons (hence the name). This is still reflected in the API’s we currently provide: these are mainly geared towards the kind of functionality we expect add-ons to require.

In the future, however, our goal is to make the Add-on SDK the SDK of choice for all new Firefox features, not just add-ons. By providing a powerful set of platform APIs in JavaScript, we hope to attract new contributors, and create a strong incentive to write as little platform code in C++ as possible. If we do our job right (and I’m really hoping we will), the Add-on SDK could be the solution to the cruft problem.

How to get there

As a first step towards making the SDK the platform API of choice, we need to make it part of Firefox itself. We just accomplished a major step in that direction by landing the SDK’s APIs and module loader on mozilla-central. They are on track to be shipped for Firefox 21.

Obviously, we are not there yet. Another step will be to figure out what kind of API’s we need to extend the usefulness of the SDK beyond that of creating add-ons. If those API’s are not powerful enough, or inconvenient to use,
platform developers will avoid them, so doing this step right will be crucial to our success.

Figuring out what kind of API’s we need will be one of the focuses of our upcoming workweek in March, during which we hope to get a much better picture of what kind of functionality platform developers expect from the SDK.

Last, but not least, another exicting development is that the SDK team has recently become part of the Developer Tools team. Developer Tools is a natural target audience for the SDK. By working closely together we hope to make the creation of developer tools easier, and improve the SDK at the same time.