WebKit and GNOME

[Maciej Stachowiak <mjs apple com>]

Hello GNOMErs,

Some of you may remember me from back in my GNOME development days.  
These days I work on WebKit, an open source Web content engine. I've  
heard that WebKit is of interest to the GNOME/Gtk community, and I  
have followed the Gtk+ port in WebKit trunk closely. Since WebKit/Gtk+  
is now under consideration as an external dependency for GNOME, I  
thought I'd share some information about WebKit from my perspective.

I think the GNOME project has to decide for itself, so I'm going to  
try to avoid excessive marketing, but obviously it is impossible for  
me to completely avoid bias.

One thing to consider is whether WebKit's goals are aligned with  
GNOME's requirements for a Web content engine. I don't think I can  
describe them better than our statement of project goals: <http://webkit.org/projects/goals.html 
>.

I think WebKit has a couple of strengths from the perspective of  
desktop integration. The WebKit project sees itself as a technology  
provider, not an end-user product. For this reason, we put a high  
priority on making the engine usable for a wide variety of  
applications, and on enabling tight integration with different  
environments. As a result of this focus we have:

1) Easy to use platform-native APIs on each target platform. The Mac  
OS X port's Objective-C/Cocoa API has been widely praised, and the Qt  
and Gtk+ ports provide their own native-feeling APIs. Here is a  
partial (and somewhat out of date) list of the many applications using  
WebKit: <http://trac.webkit.org/projects/webkit/wiki/Applications%20using%20WebKit 
>.

2) Extensive use of platform-native APIs and services. Our porting  
layer is designed to build on top of a capable underlying operating  
environment, and to make use of its services. This reduces code  
footprint (no need to duplicate code that is already in platform  
libraries) and enables tight integration.

More generally, we let platform owners decide on the strategic  
direction for their port's API and platform integration. Apple owns  
the Mac port and generally takes the lead in deciding what the API  
looks like on Mac OS X, but the Qt and Gtk+ ports are designed by  
TrollTech and by Gtk+-focused WebKit developers respectively.

Besides these strengths from the point of view of integration, I think  
WebKit has a number of other strengths:

1) Web standards compliance. WebKit has a high degree of Web standards  
compliance. We not only get the basics right but are often the first  
to pass standards compliance torture tests like Acid2, and recently  
Acid3: <http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/ 
>. We have also been pushing ahead with early support for forthcoming  
new standards like CSS3 and HTML5.

2) Performance. Our performance rocks. You can find lots of benchmarks  
out there for speed and memory and WebKit isn't the winner of every  
single one, but you'll find that we're often first and rarely last.  
With memory use the story is somewhat more complicated. Our memory use  
depends partly on the platform integration layer (images in the memory  
cache are a large component) and partly on low-level bits of the  
custom allocator. It is much better on Mac OS X than Windows, because  
our custom allocator supports returning memory to the system. I  
believe this code will work on other Unix-like platforms (such as  
Linux), but I haven't personally tested. We're hoping to make it work  
on Windows as well. In all fairness I have to say that other engines  
such as Gecko (from Mozilla) and Presto (from Opera) are also quite  
good in many performance metrics, especially with recent improvements.  
In addition to browser performance, we've also done optimization  
specifically for mail and instant messaging clients, and RSS readers.  
One result of this is a scalable memory cache, so that WebKit in IM  
clients uses much less memory than in a primary web browser.

3) Web compatibility. Web standards are nice and all, but, at least in  
the browser, the bottom line for users is whether they can use the  
sites they want to. Realistically, a lot of this depends on market  
share. Internet Explorer and Firefox often have an edge simply because  
Web developers are more likely to test in those browsers first.  
However, increasingly Web developers are testing in Safari early, or  
even developing in Safari first. Safari's growing market share, the  
iPhone, and the popularity of WebKit as a browser engine on mobile  
platforms are all giving major web developers more incentive to test  
with us. In addition, we have done huge amounts of compatibility work.  
In the span from Safari 2 to Safari 3, we fixed thousands of web  
compatibility bugs and in particular made huge strides with rich text  
editing (a longstanding problem area).

4) Hackability. I think our greatest strength is the hackability of  
our code. Although a Web content engine is intrinsically pretty  
complicated, we put a huge focus on simplicity and understandability,  
both in initial development and constant aggressive code cleanup.  
This, combined with our extensive regression test suite, allows us to  
make progress very quickly, and makes it easy to customize WebKit for  
particular applications as needed.


To be fair, I think there are also weaknesses that need to be  
addressed in WebKit in general, or in the Gtk+ port in particular:

1) BuildBot and regression test integration. The WebKit/Gtk+ port is  
not yet set up to run our regression test suite. We think having this  
set up is important to ensure that the rapid pace of WebKit  
development doesn't constantly break the Gtk+ port, and that the Gtk+- 
specific parts are working as expected. This shouldn't be too much  
work to set up, as there are Mac, Windows and Qt versions of the  
regression test tool already.

2) API completeness. Some advanced parts, like a GObject API to the  
DOM, remain to be done.

3) Linux/Gtk-specific performance tuning. Most WebKit performance work  
has been done on Mac or Windows, probably running speed tests,  
profilers and memory tools on the Gtk port would find platform- 
specific areas that can be improved.

4) Accessibility. This is only implemented in the Mac port currently.  
We are moving the core accessibility code to be cross-platform, which  
should make it fairly straightforward to hook it up to ATK or other  
accessibility APIs. Sometimes ARIA is mentioned in the context of  
accessibility - this is an interesting technology for future web apps,  
but I believe basic accessibility integration for web content is a  
higher priority.


I'm also happy to answer technical questions about WebKit, or what our  
development process is like. I will defer to the WebKit/Gtk+ crew for  
Gtk-port-specific questions, however.


Regards,
Maciej