Hacker News Reader

Comment by jheimark | Hacker News Reader

I am surprised at how heavily the number of lines of code factored into the decision to choose KHTML. It makes sense that a smaller codebase is much easier to jump into, and usually means cleaner architecture, but I didn't expect to see it addressed as such an important factor.

View on HN

At the time the minimum RAM requirement for Mac OS X was only 128 MB. WebKit was to be a system component, so it would be active in memory much of the time. Under these circumstances every MB of code counts, so it's easy to see why the leaner codebase of KHTML was found appealing.

However, I think there was also the psychological factor of Mozilla's reputation at the time as an open-source quagmire. The Netscape 4 code they had inherited was deemed unmaintainable, and so Mozilla started over with a rewrite that many thought was too complex and tried to reinvent everything under the sun (e.g. it contained a version of Microsoft's COM). Mozilla turned out fine eventually, but back in 2002 this wasn't quite so obvious.

> Mozilla turned out fine

Not exactly. There's a reason WebKit saw wild adoption by all sorts of projects, while Gecko adoption stagnated. The Mozilla codebase is still too complicated for most people.

Arguably, though, even if Gecko's code base were taken down to be smaller and easier to use than WebKit (and I have no idea how it actually compares today), it would be at a tremendous disadvantage because so many projects have incorporated WebKit.

If I want to use WebKit in a new project today, I can find a ton of people online who have done so in the past and use their experience to get me through it. If I want to use Gecko in a new project, I will have a considerably smaller amount of outside experience to lean on.

Yea, the Mariner cancellation meant that Netscape had no browser to compete in time for IE5, and Netscape 4 had many problems.

A significantly smaller codebase should produce a faster engine. Generally less work on the CPU.

just in case you're wondering why you were downvoted (I can't do that myself) -- size of code has almost 0 relation with CPU time. A small algorithm could be extremely computationally intensive

Reply on news.ycombinator.com