Mozilla is actually pretty good guys!

I’ve not blogged in a while, but now we’ve released, I figure it’s time to break radio silence. Since we were assimi^Wacquired, I’ve been hard at work on browser bits. I’ve already blogged about the headless Mozilla back-end and accompanying Clutter library; since then we’ve created a Mozilla services daemon and we’ve made the source code for the browser public.

I’ve been meaning to blog for a while about Mozilla, and the current trend of abandoning it in favour of WebKit. I’m not against WebKit and there are definitely advantages it has over Mozilla in certain situations, but I’d like to highlight some of the great things in Mozilla and why I think we ought to reassess the whole webkit move.

Comparing Mozilla and WebKit is quite a difficult task. They’re extremely different. Yes, you can use both to render web pages, but WebKit won’t do much more and it’s the least that Mozilla can do. This difference affects things at pretty much every level; their structure, their API, their coding styles, their build systems, everything. I’d also say that, in the long run and given its current maturity, this is a huge advantage for Mozilla. Want a download manager? Just use the built in Mozilla download manager. Want to override it? Sure, that’s fine, just implement the interface and register it at run-time. This is the same for pretty much any component you can think of that may be required for anything web-related. Use WebKit and you’ll have to implement all of these things from scratch, there’s no fallback option (generally). On the other hand, the WebKit API to implement these things will probably be a bit nicer. Swings and round-abouts.

And that whole run-time overriding thing? Very cool. Pretty much everything in Mozilla has an interface definition and is accessible and overridable via XPCOM. At runtime. Anything that uses Mozilla has a powerful and accessible extension mechanism, something that I don’t believe WebKit can boast. Not only does it have this mechanism, but there’s already a huge community of talented developers that are well versed in it.

The last advantage (that I’ll mention) that I think Mozilla has over WebKit is a slightly political one; From my experience (and this is purely anecdotal, I don’t mean to offend anyone), the Mozilla developer community is a lot more open and a lot more willing to take risks. I think their extensible architecture helps this, but it does seem to be a prevailing mindset amongst Mozilla developers. They really want to see Mozilla succeed in every way, and to encourage its development in all directions. Obviously, I’m sure the powers that be also want to see WebKit succeed, but it’s not the innocent, wide-eyed enthusiasm that I’d like to think embodies Mozilla developer spirit. The fact that I’ve been given a repository hosted upstream at Mozilla.org for our headless backend says something, and the amount of support and encouragement I’ve received from Mozilla developers has been nothing short of astounding.

So why exactly did we (Gnome) abandon Mozilla? Maybe people thought that contributions to the gtk embedding API (which has some annoying bugs and an API that could really use some love) wouldn’t be accepted? From my experience, I think this would be highly unlikely. Why exactly are we creating an entirely new backend and API for a new rendering engine (an API that bears an eery resemblance to gtkmozembed anyway, in a lot of places) when we have a perfectly capable, and in fact more than capable platform, funded by a foundation and accepting of contributions? There are a lot of problems with Mozilla. I do wish they used autotools, for example, and I’ve often run across a bug in my code that’s down to me not having some obscure and highly undiscoverable knowledge… But these problems can be fixed… And are becoming fewer… So what’s the deal?

]]>

Leave a Reply

Your e-mail address will not be published. Required fields are marked *