OmniWeb 5.0

Saturday, 21 August 2004

I’ve been using OmniWeb as my main browser for the last two months
(which, obviously, includes the tail end of the beta period), and I’m
still impressed. For my overall impressions of the software, the review
of the public beta still stands — most of The Omni Group’s work since
then has been bug-fixing and performance improvements.

Speaking of which, I complained that the public beta felt somewhat
sluggish. This has been rectified. OmniWeb 5.0 still doesn’t feel quite
as snappy as Safari or Camino, but it’s fast enough.

In a nutshell, here are the reasons I’ve made OmniWeb my default browser:

Saved State. OmniWeb saves the state of your entire browsing
session when it quits. When it relaunch, your windows, tabs, and
page contents are restored. Every browser should work this way.
(If for some perverted reason you don’t like this, it’s optional.)

Drag-and-drop Tabs. OmniWeb’s “tabs” are thumbnails in a
drawer. I happen to prefer this implementation to the traditional
bar-of-tabs approach used in other browsers such as Safari and the
Mozilla family. The biggest advantage to Omni’s implementation is
that tabs can be dragged — both to rearrange their order within
a window, and also to be dragged to other windows.

Per-Site Display Preferences. If you want to change the default
font size for a particular site, OmniWeb allows you to do so without
changing the default font size for all sites. Same for other display
preferences, such as the user agent string OmniWeb uses to identify
itself.

Still in the Rendering Ghetto

Now, the bad news. As stated in my public beta review, Omni made an
engineering decision to base OmniWeb 5’s rendering engine on the
lower-level open source WebCore, rather than the higher-level
Web Kit.

Omni had their reasons for doing so (see the public beta review
for details). The enormous downside to this decision, however, is that
OmniWeb’s rendering capabilities are woefully behind the times. OmniWeb
5.0’s rendering engine is based on WebCore v85, which corresponds to
Safari 1.0 from June 2003. The current version of Safari (1.2.3) is
based on WebCore v125.9.

Safari 1.0 contained a very good, very capable rendering engine. But
Safari 1.2’s renderer is much better, and much more compatible. When web
developers test for browser compatibility, they test against the latest
version of Safari. This means that some sites that work in Safari 1.2 do
not work in OmniWeb 5.0.

A prime example is Gmail — works great in Safari 1.2, doesn’t
work at all in OmniWeb 5.0. The Gmail web application depends on
features that simply aren’t supported in OmniWeb’s old version of
WebCore.

The good news is that OmniWeb 5.1 is slated to include an updated
version of WebCore. But by the time it ships, it might be obsoleted by
the next version of WebCore. Because Omni is customizing WebCore with
their own features, it’s not a matter of merely “dropping in” an updated
version. This is exacerbated by the fact that Apple’s engineers did not
intend for Mac developers to use WebCore directly — Web Kit is the
project that Apple has designed for developers to use easily.

The result is that using OmniWeb requires a trade-off. You get some very
nice browser application features, but at the expense of using a
slightly outdated and less-compatible rendering engine.

The Omni Group’s challenge is to catch up to the current version of
WebCore, and to stay there. Because other browser developers — like say
Safari’s and Camino’s — are surely taking a long look at OmniWeb’s best
features.