WebKit and GNOME
- From: Maciej Stachowiak <mjs apple com>
- To: desktop-devel-list gnome org
- Subject: WebKit and GNOME
- Date: Tue, 1 Apr 2008 10:22:12 -0700
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
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
>. 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
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.
] [Thread Prev