KHTML vs. Gecko vs. Trident vs. Presto: Behind the Browser

If anything, most Internet users concern themselves about which Web browser is more secure. Should they worry instead if older versions of Apple's (Nasdaq: AAPL) browser were better because they used KHTML? Or that maybe the security and usability of Mozilla's Firefox browser is better because it uses Gecko? Could Microsoft's (Nasdaq: MSFT) Internet Explorer 7 (IE7) be a better browser choice today because it uses the Trident engine? Why are there so many different options to begin with?

"Why do we want more than one layout engine? It helps to spur innovation and means that if a flaw occurs it won't necessarily be in every browser at once. Having some different implementations of anything is a good thing," Gene Spafford, computer science professor at Purdue University, told LinuxInsider.

What Are They?

The three main Web engines in mainstream use today are Trident, Gecko and Presto. IE7 is based on the Trident layout engine.

Mozilla uses Gecko in Firefox and the Thunderbird e-mail client, as do several other open source Web browsers. Opera Software uses Presto as the layout engine in its browser. So does Nokia (NYSE: NOK) in its Internet Tablet products. Also, Nintendo products are based on the Presto engine.

Apple eventually broke from the KHTML mold. It used some of the KHTML code and grew it into its own Web engine called WebKit.

"KHTML doesn't really exist in a relevant fashion anymore," Guy Lunardi, product manager for Novell (Nasdaq: NOVL) , told LinuxInsider.

Do Differences Matter?

Both the Apple Safari browser and the Apple iPhone use WebKit. However, WebKit's popularity extends beyond Apple, according to Lunardi.

Adobe (Nasdaq: ADBE) AIR (Adobe Integrated Runtime) and Nokia's smartphone line are using WebKit today.

Don't, however, suggest to Lars Knoll, the creator of KHTML who is now a software developer for Trolltech, that his legendary browser layout engine is a has-been. KHTML's source code is a lot smaller and easier to work with than Gecko, he explained.

"In terms of what's new with KHTML, I think the main news currently is the ongoing effort of trying to mend the fork between KHTML and the WebKit project," he told LinuxInsider in an interview from his office in Oslo, Norway.

In the Beginning

KHTML began as part of KDE 2.0, a desktop environment in some Linux operating system distributions. KHTML was an endemic part of the Linux Web browser Konqueror and KDE's integrated KHTML-powered Web browser and file manager.

It was a mainstream rendering engine solution as the popularity of the Netscape browser was waning. Back then the folks at the Mozilla Foundation were still experiencing the birth trauma of separating its open source browser from the Netscape source code around Gecko.

"While the focus of Gecko in the early years has been to build up a complete development platform, KHTML has always just focused on being an HTML rendering engine," Knoll said. "The idea behind KHTML was to create a standards-compliant HTML rendering engine that could handle all -- at that time -- modern Web pages using CSS (cascading style sheets) and JS (JavaScript)."

Mozilla/Gecko was a project paid for by Netscape and then AOL. Later, the Mozilla Foundation fostered a large amount of paid people working on the Gecko engine, he added.

"KHTML was a project purely driven by volunteers until Apple got involved. None of the people that worked on KHTML until 2003 ever got paid for the work we did," explained Knoll.

The Path Divided

The goals of both rendering projects are similar. While many differences exist on the inside, they both provide a standards compliant HTML engine that can deal with all Web pages built on the net. Today, both engines support more or less the same feature set: HTML 4.1, XHTML, CSS 2.1, JavaScript and Ajax-type Web applications, said Knoll.

One of Knoll's main focus areas from the very beginning, he said, was to try to make the architecture as sound and as easy as possible for an HTML rendering engine. This made it a lot easier for people to start working and contributing to the project.

"It was also probably the main reason for Apple to go with KHTML instead of Gecko for its Safari Web browser," Knoll proffered.

Novell's Lunardi agrees that the performance among these Web browser layout engines is seamless. They all have to implement a lot of standards and specs, including HTML, CSS, XML Document Object Model, RDF (resource description framework), JavaScript and much more.

Same Differences

These different engines exist because they were developed by different groups for different needs. In reality, they all provide generally the same end goals.

"As such, they will handle the combinations of these in different ways. They will be true to the specifications in different ways. They will handle errors and poorly formatted content in different ways," Lunardi said.

Knoll maintained the KHTML project until 2003, when others took over so he could move on to related work. In a sense, his work as a software developer has come full circle. Last autumn he went to work on WebKit, trying to get that rendering engine integrated into the Linux desktop environment KDE 4.

No Best Choice

Users would be hard-pressed to select a specific Web browser solely on the basis of which layout engine it uses. None of the engines residing on the same system cause conflicts for users or headaches for software developers, according to Knoll.

The choice of layout engines is largely a flavor additive for browser developers. For instance, KHTML is a lot better suited for embedded devices due to its smaller memory footprint. Gecko has more market share, explained Knoll.

Some minor issues exist for Web developers, but most of these are fairly trivial, Knoll said. The biggest headache for Web developers is probably the difference between the browsers that aim at standards compliance (Gecko, KHTML and WebKit) and IE.

"In the end, it's often a matter of taste which browser someone uses. On Linux one has three possibilities: Firefox -- or another Gecko-based browser -- Konqueror or Opera. As a user, you can simply pick whatever you like best," Knoll concluded.

Why Not One?

Why shouldn't there be a single standard engine for all browsers? Knoll sees two reasons why having just one rendering engine would not be good for consumers.

Having only one implementation will never give you any guarantees that what the engine implements matches the documentation. It will also never guarantee that standard is implementable by anyone else, he said.

Having several engines is good, as it triggers competition -- there is no need to improve if you have a monopoly, he reasoned, echoing Spafford's view.

"We've seen this in the browser area in the last years, where every engine tries to be as fast as possible and/or as standards-compliant as possible," he said.