Hyatt on Safari's choice of KHTML.
The following was posted at Hyatt's blog for a very short period of time...it was then removed and a less pointed version was posted. I'm providing it because it went on the web, making it free game, and because I do not think it is very incendiary...it does a nice job of explaining why the primary mind behind Chimera helped choose a different code base for Safari:
"Now 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.
The problem is, how do you make Gecko have a fast startup time on the Mac? Comparing Chimera's slow cold launch with its zippy warm launch, it's readily apparent that much of Gecko's startup time problem on the Mac is due to the enormous code footprint. So, in order to use Gecko, your first task would be to shrink this code footprint. So how do you do it? Well, you'd have to deCOMtaminate a lot of the core code, eliminate redundant interfaces, and in some cases re-architect dramatically a lot of components so that they didn't need to exist. For example, Gecko has its own image loading library, which you would want to eliminate in favor of simply using the operating system's image capabilities. Ditto for networking.
Now look at KHTML, which dropped in as is (with QT implemented) gives you a fast startup time right off the bat, because the code is so small and well-designed that you don't even have to worry about startup. A whole huge set of tasks eliminated simply by picking KHTML over Gecko.
Next consider the problem of native widgets. KHTML has a clean separation of the form controls as native components (using QWidget and QInterfaces to communicate), so all you have to do is back those QInterfaces with Cocoa implementations and bang, you have native form controls.
The same problem in Gecko is months of work. You have to develop these interfaces for each widget (they don't exist), and then slowly but surely get native widgets working again. You'd have to completely rearchitect all the form control render objects in Gecko to talk to native widget interfaces. Then you get to have fun fighting all of the bugs from a brand new forms implementation and again would probably have to modify other parts of Gecko to support these new form controls.
So to summarize: with KHTML what you have is a tiny engine with reasonable standards compliance and native widgets that would need to become a tiny engine with native widgets and outstanding standards compliance. WIth Gecko, you have an enormous engine with outstanding standards compliance and non-native widgets, that would need to become a small engine with native widgets while still retaining outstanding standards compliance.
Which task is going to be easier? There's no question that both involve heavy modification of the layout engine, and both involve a lot of work, so then the question becomes, Which one is easier to modify? In my opinion (speaking only for myself), the answer is KHTML. I won't pretend that the choice of KHTML over Gecko is a no-brainer (it's not), but for those of you who think standards compliance is the only consideration when developing an outstanding browser engine, well, hopefully this will give you some food for thought."
Me? I still love Chimera, and I am glad that now we have some real variety and competition in the browser market.
"Now 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.
The problem is, how do you make Gecko have a fast startup time on the Mac? Comparing Chimera's slow cold launch with its zippy warm launch, it's readily apparent that much of Gecko's startup time problem on the Mac is due to the enormous code footprint. So, in order to use Gecko, your first task would be to shrink this code footprint. So how do you do it? Well, you'd have to deCOMtaminate a lot of the core code, eliminate redundant interfaces, and in some cases re-architect dramatically a lot of components so that they didn't need to exist. For example, Gecko has its own image loading library, which you would want to eliminate in favor of simply using the operating system's image capabilities. Ditto for networking.
Now look at KHTML, which dropped in as is (with QT implemented) gives you a fast startup time right off the bat, because the code is so small and well-designed that you don't even have to worry about startup. A whole huge set of tasks eliminated simply by picking KHTML over Gecko.
Next consider the problem of native widgets. KHTML has a clean separation of the form controls as native components (using QWidget and QInterfaces to communicate), so all you have to do is back those QInterfaces with Cocoa implementations and bang, you have native form controls.
The same problem in Gecko is months of work. You have to develop these interfaces for each widget (they don't exist), and then slowly but surely get native widgets working again. You'd have to completely rearchitect all the form control render objects in Gecko to talk to native widget interfaces. Then you get to have fun fighting all of the bugs from a brand new forms implementation and again would probably have to modify other parts of Gecko to support these new form controls.
So to summarize: with KHTML what you have is a tiny engine with reasonable standards compliance and native widgets that would need to become a tiny engine with native widgets and outstanding standards compliance. WIth Gecko, you have an enormous engine with outstanding standards compliance and non-native widgets, that would need to become a small engine with native widgets while still retaining outstanding standards compliance.
Which task is going to be easier? There's no question that both involve heavy modification of the layout engine, and both involve a lot of work, so then the question becomes, Which one is easier to modify? In my opinion (speaking only for myself), the answer is KHTML. I won't pretend that the choice of KHTML over Gecko is a no-brainer (it's not), but for those of you who think standards compliance is the only consideration when developing an outstanding browser engine, well, hopefully this will give you some food for thought."
Me? I still love Chimera, and I am glad that now we have some real variety and competition in the browser market.
Comments
Very interesting read. You're right, it's really not incendiary, other than he does make direct comparisons to Gecko, usually to its detriment though of course they are valid points and not rejecting it outright, only in the context he creates.
Dave
<strong>Isn't one of Chimera's founders on the Safari team?</strong><hr></blockquote>
Yes, his name is in the title of this thread
<strong>Isn't one of Chimera's founders on the Safari team?</strong><hr></blockquote>
yes, hyatt.
interesting read. nice to see his perspective on the whole chimera/khtml issue. however, i think another reason they went with khtml, which i don't know if anyone has touched on yet is that there is no other khtml project that i know of running on the mac platform. this is very important when you consider the fact that both mozilla and khtml are both open source projects. why? simple, any improvements or changes to the code must but submitted back to the project. in the case of mozilla, apple would not only be improving their own code base but potentially that of mozilla, chimera, and netscape just to name a few. why help out your competitors if you don't have to. a very shrewd move by apple imho.
I suppose it might be considered a bit impolite to point out so pointedly Gecko's flaws on mozillazine.org...
<strong>however, i think another reason they went with khtml, which i don't know if anyone has touched on yet is that there is no other khtml project that i know of running on the mac platform. this is very important when you consider the fact that both mozilla and khtml are both open source projects. why? simple, any improvements or changes to the code must but submitted back to the project. in the case of mozilla, apple would not only be improving their own code base but potentially that of mozilla, chimera, and netscape just to name a few. why help out your competitors if you don't have to. a very shrewd move by apple imho.</strong><hr></blockquote>
If they did think of that, it's a transient advantage at best, because they published WebCore. So their "competitors" can avail themselves of the rendering code just as easily as they can. As with the other frameworks on OS X, every improvement Apple rolls into WebCore will automagically improve any other browsers (or other applications) that use it.
This is a far more shrewd move, IMO. Apple is selling the platform, not the browser, and WebCore significantly enhances the platform.
<strong>
If they did think of that, it's a transient advantage at best, because they published WebCore. So their "competitors" can avail themselves of the rendering code just as easily as they can. As with the other frameworks on OS X, every improvement Apple rolls into WebCore will automagically improve any other browsers (or other applications) that use it.
This is a far more shrewd move, IMO. Apple is selling the platform, not the browser, and WebCore significantly enhances the platform.</strong><hr></blockquote>
i must have missed the whole webcore bit. not sure exactly what that is. the name sounds real familiar though. is it more or less a service (is that the right term?) that any application that is written properly could take advantage of? if so then for mozilla to benefit from apple's code, they would have to do away with geko?
<strong>
yes, hyatt.
interesting read. nice to see his perspective on the whole chimera/khtml issue. however, i think another reason they went with khtml, which i don't know if anyone has touched on yet is that there is no other khtml project that i know of running on the mac platform. this is very important when you consider the fact that both mozilla and khtml are both open source projects. why? simple, any improvements or changes to the code must but submitted back to the project. in the case of mozilla, apple would not only be improving their own code base but potentially that of mozilla, chimera, and netscape just to name a few. why help out your competitors if you don't have to. a very shrewd move by apple imho.</strong><hr></blockquote>
Yes, perhaps even more importantly there is no KHTML based Windows browser and thus if apple manages to make the fastest or best, or fastest and best, browser they will be able to make the claim the fastest browser available in consumer OS
So Apple is "integrating" the web browser into the OS, except that unlike MS, it's perfectly modular and optional to use.
<a href="http://developer.apple.com/darwin/projects/webcore/index.html"; target="_blank">http://developer.apple.com/darwin/projects/webcore/index.html</a>;