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.
How the Add-on SDK can help
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
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.
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.
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.