C|NET Article Examines Apple's Choice Of Browser Engines For Safari
by , 6:15 PM EST, January 14th, 2003
When Steve Jobs told the world that Apple had created another browser many could have sworn they heard a collective, "Huh?"
Apple's first attempt at making its own web browser, Cyberdog, met with mixed reviews and was ultimately canned, though there are still many who believe Cyberdog was a browser too far ahead of its time.
This time Apple eschewed internal browser development and went in search of a top notch standard on which to base Safari, its newest browser. Apple engineers literally could have picked anything on which to base Safari, including the Gecko rendering engine which powers the latest versions of Netscape, Mozilla, and Chimera, but the company instead picked open source KHTML. According to a C|Net article titled Apple snub stings Mozilla, Apple picked KHTML purely on its technical merits and not for any political reasons, as some may believe. From the C|Net article.
In an e-mail congratulating KHTML engineers on their work and its selection by Apple, Safari's engineering manager touted the technology over Mozilla and its rendering engine, Gecko.
"When we were evaluating technologies over a year ago, KHTML and KJS stood out," Safari Engineering Manager Don Melton wrote. (KJS is KDE's JavaScript interpreter.) "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."
Despite its diplomatic tone and anonymous reference, Mozilla veterans read between the lines of Melton's message.
In a Web log , Mozilla founder and former evangelist Jamie Zawinski said Apple is bad-mouthing Mozilla.
"Translated through a de-weaselizer, (Melton's e-mail) says: 'Even though some of us used to work on Mozilla, we have to admit that the Mozilla code is a gigantic, bloated mess, not to mention slow, and with an internal API so flamboyantly baroque that frankly we can't even comprehend where to begin,'" Zawinski wrote.
One Mozilla staff member called KHTML selection an understandable if not foregone conclusion, given Mozilla's technical problems.
"I guess I'm supposed to be mortally offended--or at least embarrassed--that they went with KHTML instead of our Gecko engine, but I'm having trouble working up the indignation," wrote Mike Shaver in a Web log posting . "We've all known forever that Gecko missed its 'small-and-lean' target by an area code, and we've been slogging back towards the goal, dragging our profilers and benchmarks behind us, for years."
Read the full article at C|Net News.
That Apple picked KHTML over any other browser engine could mean many things to many people. In the case of the Mozilla/Gecko folks, it could mean that the industry at large will look upon Gecko based browsers as being inferior to KHTML. Certainly there's internal discussion within Mozilla's own team as to the technical merits of their product, but it is our opinion that Mozilla is also a very solid browser.
In the long run, Apple's choice could mean absolutely nothing at all to the Gecko/Mozilla effort. There is certainly room in the market for many different browsers, despite what the folks at Big Redmond might think. Apple simply had certain criteria in mind when it went hunting for an engine. KHTML met those criteria; Gecko/Mozilla did not. It doesn't mean that the Gecko engine or Mozilla based browsers are bad, it just means that KHTML had what Apple was looking for.
Mac users certainly seem to like Apple's choice of browser engines, according Apple, we've downloaded Safari more than 500,000 times.
We believe the Gecko/Mozilla team really don't have any reason to complain or feel slighted, Safari won't seriously hurt their efforts and it gives Mac users another choice. Choice is almost always a Good Thing.