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.
No comments:
Post a Comment