Sun, January 12, 2003

KHTML and Gecko

David Hyatt discussed in more detail why Apple would chose KHTML over Gecko as the engine for the Safari browser. Unfortunately it has been taken down now. John Gruber apparently saw it, too, and quotes the following snippet over on his Daring Fireball site:

Imagine that your number one priority for a browser is speed. You want a browser that launches almost instantly. You want a browser whose page load peformance can be improved dramatically. This is your number one goal, because you want to address what has been a fundamental problem on your platform (OS X) ever since it was launched: that no browser has accomplished the goal of fast startup and fast page load. Your job is to find an existing open source engine and improve it to the point where it does have fast startup and phenomenal page load times.

Hyatt also pointed to David Baron’s review of the Gecko layout engine for examples of the challenges facing a company seeking a layout engine. Hyatt essentially said that in order to use Gecko to accomplish Safari’s speed goals, Apple would have had to significantly rearchitect some parts, drastically trim or remove several libraries, such as the image and network libraries that were redundant with Mac OS X libraries, and learn Gecko’s unique terminology for everything. With KHTML they did not need to rearchitect because they found it already small and well-designed. But it cost them the unmatched standards support of Gecko. It will be interesting to see how these comparisons motivate improvements in both engines.

Update: jwz saw it too and points to the LiveJournal archive of Hyatt’s post. He says Hyatt says he is working on a more accurate version.

Safari debugging     I can hear you