OmniWeb 5.0

Saturday, 21 August 2004

Back in February, I reviewed the public beta of OmniWeb 5, and I was impressed. Last week, OmniWeb 5.0 finally shipped.

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.