Why Mozilla is committed to Gecko as WebKit popularity grows

 

Why Mozilla is committed to Gecko as WebKit popularity grows

After Google's recent release of the WebKit-based Chrome browser, some of our readers have been wondering if Mozilla's Gecko rendering engine is still relevant. Ars takes a close look at Gecko and WebKit and explains why Gecko will continue to put the fire in Firefox.

By Ryan Paul | Last updated September 9, 2008 1:30 AM CT

Webkit's strengths

In the wake of Google's release of the new WebKit-based Chrome browser, some technology enthusiasts are beginning to wonder if the days are numbered for Mozilla's Gecko rendering engine. Despite the growing popularity of WebKit, those who understand the differences between the two rendering engines and have an appreciation of Gecko's technical strengths, recognize that there is no basis for speculation about the possibility of Mozilla adopting it for future versions of Firefox.

WebKit is an open-source HTML rendering engine that was developed by Apple with code from KDE's KHTML project. As we noted in our Chrome review, WebKit is an extremely lightweight renderer that is often praised for its tight and clean code base, excellent standards-compliance, and small memory footprint. These characteristics have made it a popular choice for browser implementers and numerous other adopters.

WebKit is primarily used in Apple's Safari web browser and on the iPhone, but high-profile third-party users include Adobe, Nokia, and Trolltech. WebKit is also used by a multitude of other lesser-known browsers, including iCab, Omniweb, Shiira, and Epiphany. It's a favorite in the alternative-OS community as well, and is making its way to Haiku, Syllable, and even Amiga. On the Linux desktop, programmers (including myself) are increasingly using it to build rich Internet applications. After evaluating all of the available choices, Google saw WebKit as the obvious choice for both its Android mobile browser and for Chrome on the desktop.

The consensus of the developers who are using WebKit is clear: it's an outstanding rendering engine that lends itself to an extremely diverse assortment of practical uses. It is everywhere, and it is gaining traction at a very impressive rate. That traction is causing some developers to question whether Mozilla's Gecko rendering engine is still relevant.

Why Apple rejected Gecko

Gecko, which originated at Netscape and predates KHTML, is often criticized for its large and infamously complex code base. Gecko has always been extraordinarily powerful, but its richest and most impressive capabilities originally came at a high cost in size, complexity, and memory overhead. The consequence is that Gecko is unsuitable for adoption in many places where its additional functionality is an impediment instead of an asset.

One of the primary reasons for the enormous complexity of the Gecko code base is that it aims to provide much more than just an HTML renderer. Mozilla's early goals were extremely ambitious—the original Mozilla application suite included a browser, a complete mail and newsgroup program, a web design tool, and an IRC client. In addition to rendering HTML, Gecko also provides a versatile XML-based user interface rendering framework called XUL that was used extensively in those applications. XUL is still used today to create the Firefox user interface, and it facilitates that browser's support for extensions, which are regarded by many enthusiasts as one of the most valuable features offered by Firefox.

Another reason for much of the complexity in Gecko is the use of XPCOM, a powerful component system. Although XPCOM brings a lot of really compelling capabilities to Gecko and made the entire engine highly modular, some developers embraced it too enthusiastically and used it in places where it was probably not wise to do so. When Ars interviewed former Mozilla developer Scott Collins back in 2004, he listed the excessive use of XPCOM among Mozilla's top mistakes.

With all of the complexity introduced by XUL and XPCOM, it made sense for Apple to choose something lighter for Safari. Apple wanted to make a browser that could be integrated tightly with Mac OS X. It's also possible that they foresaw the need for a rendering engine that could scale down to a mobile device, a factor that also made KHTML a better solution than Gecko at the time.

When Apple chose to use KHTML for Safari in 2003, Mozilla's Mike Shaver responded with a blog entry acknowledging Gecko's weaknesses. He also astutely predicted that Apple would become an ally in promoting open web standards and that Apple's decision to create its own browser would provide many opportunities for mutual learning and improvement.

"Gecko missed its 'small and lean' target by an area code, and we've been slogging back towards the goal, dragging our profilers and benchmarks behind us, for years. If I had to write a new browser, and I was going to have to touch the layout code in a serious way, I would think about Mozilla alternatives," he wrote back in 2003. "I really really hope that Mozilla will learn from Safari/KHTML, because they've done a lot of great work in about a tenth of the code."

A revamped Gecko puts the fire in Firefox 3

A lot of things have changed since 2003, and the Gecko code base has come a long way. Gecko is still very complex, but many of its historical weaknesses have been addressed by Mozilla's engineering efforts. Gecko received a massive overhaul for Firefox 3, with countless changes that significantly improved the entire browsing experience.

Gecko 1.9 uses the cross-platform Cairo rendering framework. This greatly improved SVG support simplified many aspects of the code base and facilitated some cool features, like support for full-page zooming. The overhaul also included significant refactoring of the reflow algorithm, making it possible for Gecko to pass the Acid 2 test. Mozilla also aggressively reduced memory consumption, coming out ahead of both Safari and Opera.

Usage of XPCOM has been decreased in many places over the years, and its resource overhead was reduced by the new cycle collector. This work will continue as Mozilla purges XPCOM more extensively from Gecko in preparation for Firefox 4 and replaces XPCOM reference counting with real garbage collection. Ongoing development efforts are addressing other Gecko weaknesses, too. For instance, Gecko improvements that landed in the first Firefox 3.1 alpha add support for some CSS 3 features that are implemented in WebKit. There are also lots of performance improvements that make Gecko more competitive. Mozilla's TraceMonkey engine landed in recent nightly builds and will likely be included in 3.1; it massively boosts JavaScript performance.

From a technical perspective, Gecko is now very solid and no longer lags behind WebKit. A testament to the rate at which Gecko has been improving is its newfound viability in the mobile space, where it was practically considered a nonstarter not too long ago. Mozilla clearly has the resources, developer expertise, and community support to take Gecko anywhere that WebKit can go.

• Text Size
• Download PDF (subscription required)
• Print this article
• Leave a comment

<script type="text/javascript"></script>

Why Gecko gets love from third-party adopters

It's also worth noting that some of Gecko's unique and seemingly idiosyncratic features are becoming useful to third-party adopters. There are a growing number of applications being built on top of the Mozilla platform that leverage XUL with impressive results. A few examples are the Songbird music player, the Miro video player, and ActiveState's Komodo IDE. Firefox 3 itself can be used as a XUL application runtime, which means that third-party developers can build rich Internet applications with XUL and JavaScript and deploy them with ease on computers with Firefox 3. Similarly, we are beginning to see sophisticated XUL applications deployed entirely as Firefox extensions. One example is Pencil, a diagramming and GUI prototyping tool that recently won the Extend Firefox 3 contest.

Some of the most prominent WebKit adopters are also investing considerable resources into Gecko and Firefox. Nokia, for instance, is funding the development of a Firefox Qt port and Adobe is collaborating with Mozilla to develop Tamarin, a new JavaScript engine that uses code from Flash's ActionScript virtual machine.

Gecko is clearly capable of achieving parity with WebKit in power, performance, and low memory consumption, while still providing unique and highly advantageous features that can't be found in other rendering engines or easily added to WebKit. Despite the belief of some critics that WebKit is categorically better, there is no technical basis for arguing that Firefox should drop Gecko.

Mozilla explains why WebKit isn't the future of Firefox

We asked Mike Shaver, who is now Mozilla's VP of engineering, to comment on how he views the Gecko/WebKit dichotomy today and why he believes Gecko is still important.

"I have a lot of respect for the WebKit guys, and for the work they've done," he told us in an e-mail. "The web is better because they're around and pushing hard, and Mozilla itself is better from the competitive push as well as cooperation ranging from new web standards to plugin interfaces to the nerdiest of implementation discussions."

Although he respects the technical achievements of WebKit, he believes that the WebKit development model and fragmentation in the WebKit ecosystem would create serious challenges that make it unsuitable for Firefox.

"We're getting a ton of value out of a unified engine for all our projects, from desktop to device and xulrunner to Thunderbird. If you look at the WebKit landscape right now, you see a lot of different projects there and it's not clear how or if they'll converge," he wrote. "We'd obviously need to hack WebKit pretty hard to adapt it to our needs, and it's not likely that adding another fast-moving variant to that mix would be helpful to anyone, least of all WebKit! We learned about fork maintenance and integration the hard way (and had to learn it a couple of times, to be honest), so that's not trouble that we want to borrow."

The WebKit governance model and Apple's general lack of transparency are also issues that would negatively impact Mozilla if Firefox adopted WebKit.

"I think we would have a hard time maintaining our momentum and depth of community empowerment in the WebKit setting. The level of visibility around patches and review is a lot higher in our world, as one example, and we don't have bugs disappearing into an Apple-only bug system," he told us. "For us to come into WebKit's world and insist on that additional transparency would be unfair and counterproductive, but to live without it wouldn't be an option for Mozilla. Our system works for us, and their system works for them (and is in many ways less noisy), but I don't think that any one system could work very well for both of us."

Conclusion

My hope is that this detailed examination of Gecko's strengths, and the effort that Mozilla has invested in overcoming its weaknesses, will help illuminate the continuing relevance of Gecko in the Mozilla ecosystem and finally put to rest dubious speculation about the possibility of WebKit adoption for Firefox.

The technical advantages of Gecko are evident when viewed objectively, and the amount of effort that would be required to make WebKit fit into the Firefox stack would far outweigh the technical benefits. As we have noted in the past, there are also reasons why the choice and diversity inherent in having multiple competing implementations is valuable, too.

There are many things the Gecko and WebKit developer communities can learn from each other, but replacing Gecko would not serve any justifiable purpose. In closing, I'll leave you with one more thought from Mike Shaver:

"We follow WebKit as closely as anyone in the world, and we cast as critical an eye towards our technology stack as anyone in the world," he told us. "But a brain transplant is neither practical nor likely to be useful."