Apple’s Safari Mistake: Choosing KHTML over Firefox

Just slightly over two years ago, Apple released an incredible web browser that made the world sit up and take notice, led to Microsoft discontinuing Internet Explorer for Mac OS X, and gave Mac users a browser that rendered faster, worked better, and looked cooler than just about anything else on the planet.

There was only one problem. Apple picked the wrong technology.

At the time, Apple’s technology choice sounded very good. Apple picked KHTML, the rendering engine behind Konqueror. KHTML, and Konqueror, are open source projects that produce software for KDE, or the ‘K desktop environment’ – a fairly good GUI for Linux. Since Linux and Mac OS X share significant similarities, the code was very portable.

But why did Apple pick KHTML?

The answer can be found in an email that Don Melton, the leader of the Safari project at Apple, sent to the KDE team. Basically: the code was clean, the code was fast … and there wasn’t too much of it.

The number one goal for developing Safari was to create the fastest web browser on Mac OS X. When we were evaluating technologies over a year ago, KHTML and KJS stood out. Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance as you can see reflected in the data at http://www.apple.com/safari/

If you recall, there were significant problems with Firefox (then called Mozilla) development two years ago. An ongoing problem was that there didn’t seem to be a lot of development …. new versions took ages to come out. But the second problem, and probably the one that scared Apple off most of all, was code bloat. Mozilla/Firefox had a LOT of code, was a big download, hogged memory, and was sloowwwww ….

With the information available at the time, then, Apple made the right choice. Mozilla/Firefox was fat, slow, and buggy, and therefore had a seriously bad name in the web community. KHTML was slim, fast, and clean …. and it was virtually unknown, meaning that there was no baggage for Apple to deal with.

But the world changed.

Somewhere in 2002, when Mozilla was still perceived as floundering and ineffective, a small group of key developers buckled down, battened the hatches, and totally kicked ass for almost two years straight. After increasingly good beta releases, they released a 1.0 Firefox browser that completely rewrote the story on Mozilla’s flaws. Firefox became fast, stable, lean, efficient. Slowly, but with gathering momentum, Firefox has become the web’s gold standard in browsers, pretty much due to two key reasons.

First, the key developers having a very clear focus on what they wanted. As Ben Goodger, lead engineer for Firefox development, puts it:

Our goal for Firefox has always been to create a stylish, usable browser, making as few compromises has necessary – which was largely possible by being free from commercial constraint. When I design new features, I try to think about what people are trying to accomplish, and design the feature so that it helps them as best possible. This has not always been easy. I’ve been very demanding of myself and on others that I work with, trying to exact every last ounce of usability of a given scenario. Some tasks that we have worked on have taken a considerable amount of time, much of that time spent fussing over the tiniest of details, details that in the past (when working on the Netscape product line, for example), we would never have been allowed to fret so profusely over. The result is software that works for the most part exactly as you expect it. All your settings, favorites, passwords and other data are brought in from IE, downloading files is easy and free of superfluous prompting, your passwords are entered automatically and slickly managed, just to name a few. These things are not easy, but the quality bar has to be set high to be noticed, and in that department I think our focus on detail has paid dividends.

And secondly, a large and growing community of developers have added resources and extensions to Firefox, making it even more valuable. And, importantly, leading many who might not ordinarily consider open source solutions to consider Firefox a capable and worthy choice.

So. Here we are in March 2005, with the benefit of 20/20 hindsight. Apple should have picked the non-obvious choice: Mozilla/Firefox. Today, Firefox is probably an overall better browser than Safari.

I’m a Mac user. I love Apple (although not the legal department). I love the look and feel of Safari. But I’m typing these words in Firefox. More sites work properly in Firefox. Firefox has more enhancements that let me do my job (web app development) better, easier, and quicker. It also has more enhancements that just let me surf the web smarter and get information faster.

I haven’t completely switched, but Firefox is now set up as my default browser … and I’m not the only Mac person who has done that. I get a lot of Mac visitors to this site, and I’m noticing more and more lines like this in my log files:

Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

It stands to reason that Apple cannot develop Safari as fast as the Mozilla organization can develop Firefox. There’s just too much talent there pumping out open source goodies. What can Apple do now? I have no idea.

But I’m fairly certain that Apple backed the wrong horse in this race.