Gecko vs. WebKit: Lessons Learned
I’ve had several people express strongly negative opinions to me about my Gecko vs. WebKit post. I would therefore like to clarify what I wrote and why I wrote it.
Three specific incidents spring to mind as motivations for the post. The first was at a conference last year, where a Mozilla core developer and I were admiring a portable electronic book that was amazingly easy on the eyes. The guy showing off the device told us that they had chosen some other rendering engine (I think it was Opera) because Mozilla was too heavy for their purposes. I ended up having a long discussion with the Mozilla guy about how to improve Gecko’s memory footprint, in particular by using a more efficient representation for the content tree based on a big hashtable, using tearoffs when access was needed to specific interfaces. And maybe switching from UTF-16 to UTF-8.
The second was an interview with Tristan Nitot on TechCrunch. Tristan expressed the view that allegations of Firefox’s bloat are unjustified, and many of the comments took him to task for this. A lot of TechCrunch commenters are idiots, of course, and the frustration I felt as a member of the Mozilla community on reading this was ironically similar, I’m sure, to that of a lot of people upon reading my post. Nonetheless, this really drove home to me the extent to which the perception that Firefox is a memory hog (justified or not) is widespread.
The third was last week, while on vacation with my new iPhone. Like everyone else who’s laid a hand on one, I’ve been totally seduced by the device. The web browser in particular is stunning. Well, actually it’s really slow, has no cache and lacks essential features like a clipboard and the ability to open a link in a new window or store files to disk. But it’s still the actual functioning web in your pocket. As a member of the Mozilla community, I was jealous.
From there it wasn’t much of a stretch to imagine a future Firefox based on WebKit. In retrospect, I regret two things about what I wrote. The first is that I left too much unsaid. I know that there are many difficult trade-offs in any large software development project, and Mozilla is about as big and complex as it gets. In many cases keeping memory usage to an absolute minimum was not the only goal. Much of the baggage that Gecko carries when compared to something like WebKit makes possible the extension mechanism that is Firefox’s biggest strength. You can’t have it both ways, and Mozilla is now implementing some of lessons learned (e.g. deCOMtamination) that will make Firefox leaner without sacrificing extensibility. Moreover, while I don’t think that running exhaustive benchmarks is a precondition for writing what I wrote, I should have made it clearer that I was basing my thesis on secondhand information and that it should therefore be taken with a grain of salt.
The second is the finality of my conclusion. I actually don’t believe that it’s a no brainer for Mozilla to drop Gecko; to believe so based on my limited knowledge (especially of WebKit) would be foolish. I got carried away by my own rhetoric and opted for a punchy ending. But it’s not a good idea to conclude controversial posts by voicing opinions that you don’t actually subscribe to. I should have said that it was an intriguing question worthy of investigation, not that Mozilla would be derelict if it didn’t jettison Gecko immediately. Sorry.
As far as XUL is concerned, a lot of the feedback I got pointed out the need for a migration path to HTML for application and extension chrome, even if you believe that HTML will eventually take over the role of XUL. (I was pleasantly surprised at how widely accepted this idea is.) Were Mozilla or someone else ever to take this path, I agree that XUL would have to be supported for the foreseeable future. This would mean building some sort of XUL support into WebKit. Assuming sufficient growth in HTML’s capabilities (new box models, WebForms, etc.), I wonder how much of this could be achieved with a tree transformation from XUL to HTML.
Once again, I hope this clears up any understandable misconceptions.
13 Comments »
Trackback URL RSS feed for comments on this post.
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Gecko and WebKit are both good engines. I think it’s better for the Web to have two open source implementations of Web standards. Let’s drop all the “vs” talk and just concentrate on making both engines as great as they can be.
Comment by Dave Hyatt — 10/9/2007 @ 10:29 pm
I did not replied to the previous post because i was thinking you were a victim of the iPhone sickness :-P. WebKit is nice, but still has a long way to go to match Gecko compatibility. The future is great for Gecko on small devices, do you remember the first iterations of browser on mobile phones? do you really suggested at that time to replace Gecko just to reach to those devices?
If you look at the webkit on the iPhone you will see the current equivalent small browser of those times. It is better to trim down Gecko for future devices, that will give us a better mobile browser that replacing it with a good browser for today hardware standards
Comment by Robert — 10/9/2007 @ 10:44 pm
“WebKit is nice, but still has a long way to go to match Gecko compatibility.”
It really doesn’t. More errors at this point (in Safari 3 at least) are caused by Web site bugs from not paying attention to WebKit than by actual bugs in the engine itself.
Comment by Dave Hyatt — 10/9/2007 @ 11:00 pm
“But it’s still the actual functioning web in your pocket. As a member of the Mozilla community, I was jealous.”
Schrep briefly mentioned this in your last blog post, but I’ll repeat it again because it seems you missed it.
You can already have a rather nice Gecko-rendered web-in-your-pocket with the Nokia N800 (not to mention other mobile devices that can run Minimo). Both platforms have 128MB of memory, both use ARM CPUs (although the iPhone is 620Mhz, and the N800 is 330Mhz).
From what I’ve seen from using both devices, both engines are in the same ballpark. I didn’t notice a significant subjective difference between Opera and MicroB (Gecko) on the N800. Of course, the iPhone’s UI is far better than the N800, but I don’t think the choice of rendering engine has much to do with that.
There’s a webkit port for the N800 now, and I’ve been meaning to try it out.
Comment by Justin Dolske — 10/10/2007 @ 12:42 am
Justin - but this one goes to eleven!
Comment by Matt — 10/10/2007 @ 11:17 am
I think you yanks need to take a few deep breaths. The amount of crap on the web babbling on about this bloody crApple phone is borderline hysteria. Anybody would think aliens had landed or something.
This is a bit off topic but I just love it how crApple rapes the earth for oil, turns it into the landfill tomorrow’s landfill, retrofits it with fake chrome and you all think it’s ok to be a monopoly. If Microsoft did a similar deal, locking the unit to one provider, they would never hear the end of it.
Comment by pd — 10/10/2007 @ 2:40 pm
@Dave “More errors at this point (in Safari 3 at least) are caused by Web site bugs from not paying attention to WebKit than by actual bugs in the engine itself.”
that is what i call compatibility, there always will be bad code on the web, and in my personal opinion, browser vendors pushing more HTML5 instead of XHTML, XForms, etc… will not help to reduce bad code from the net, so I think for much you want people to fix their sites to work with WebKit, it will never happen until you reach a critical mass of users, much the same thing that has happened with Gecko. but how Gecko has reached it? partly because it has a more advanced quirks mode
Comment by Robert — 10/10/2007 @ 2:44 pm
Although I have no opinion on dumping Gecko for Webkit, I am glad you are bringing up some large problems effecting Gecko. For instance, I am hearing many people complain–mostly indirectly–about the memory footprint of Firefox. Keep pushing for a better browser engine.
Comment by Seamus — 10/10/2007 @ 4:07 pm
@Robert
You misunderstand what Dave is saying. First of all, most critical compatibility issues tend to be with scripting APIs, not markup, so XHTML/XForms vs. HTML would make absolutely no difference. The problem is that many critical APIs (like editing) are not in any formal spec and not very interoperable. This is something that HTML5 is fixing, so that browsers can converge on common behavior. Working on XForms or XHTML instead will do nothing to fix current pages.
Second, Dave isn’t talking about sites that happen to work in Gecko because it has a “more advanced quirks mode”. He’s talking about sites that are only tested in IE and Firefox, and use dual code paths, so they end up depending on bugs and quirks of both IE and Firefox. We often get bug reports even about strict mode sites where we match the standard better than Firefox but the site depends on Firefox bugs. That’s not to say we are necessarily better across the board.
The conclusion here is that the best way for WebKit to improve compatibility is to promote pragmatic standards like HTML5 and to grow the market share of WebKit-based browsers.
Comment by Maciej Stachowiak — 10/10/2007 @ 6:24 pm
The “leanness” of Webkit is a myth (probably spread by dumbass Maczealots); after 3-4 hours of browsing Safari 3 uses more than 300MB of private memory (RPRVT) on my MBP.
Comment by Kula bácsi — 10/10/2007 @ 9:22 pm
Maciej: I figured Dave was referring to UA sniffing and the problems that causes.
Comment by RyanVM — 10/11/2007 @ 1:49 am
The problem is, it would basically be dumping firefox, without gecko there isn’t really much left. All of the other stuff thats left uses gecko.
That leaves you with nothing; so you’d be starting a webkit browser from scratch… but they already exist, khtml, safari and epiphany.
One of the major advantages of firefox are all the extensions that gecko makes possible, you would need to retrofit the other engines to make something similar possible, but all existing extensions would have to be dumped and restarted (unless work was done to support the apis).
Basically gecko probably was at a decentish state at about the time firefox arrived on the scene from the mozilla project.
It would probably take about the same amount of time to get a new firefox to the state the existing one is at.
As for problems like speed of rendering, resource usage etc… these are getting looked at but it seems like some things in open source take a long time.
FF has the potential to go fast with the Cairo rendering engine their using in FF3 as it can use OpenGL to accelerate the drawing. However I think it’ll take more time for optimizations to go into Cairo and for FF to take advantage of that.
One good thing in FF3 is it should finally have the new rendering engine, which parses the document structure less + allows cool things like using svg effects on html.
All good things come, but it takes a while.
Other good things coming which have taken ages and may happen in the next year or two.
The Gimp moving to GEGL (was supposed to be around the year 2000)
Wine reaching 1.0 (it’s been going 15 years at least!)
Comment by Stu — 2/10/2008 @ 4:45 am
@ Kula: That actually isn’t webkit, as other webkit-based browsers don’t suffer that error. The thing that is causing the massive amount of RAM use is a caching issue with Safari which they neglect to change (maybe it’s a feature, who knows?).
Comment by Goff256 — 5/22/2008 @ 11:52 pm