Should Mozilla Drop Gecko for WebKit?
The Mozilla wiki describes in detail the ambitious plans for Mozilla 2. I heartily agree that the time is ripe for a major overhaul of the Mozilla engine. Considering the breadth of the planned changes, it’s worth at least asking whether the Gecko rendering engine, as it exists in Mozilla 1.9, is the right basis for this work. The wiki clearly states that Mozilla “won’t rewrite the Mozilla codebase by hand,” which seems prudent. But there is a second choice: replace Gecko with another rendering engine. Any viable alternative would, of course, have to be open source and match Mozilla’s battle-hardened robustness and standards compliance while offering clear advantages. This is a tall order indeed, but there appears to be at least one plausible candidate: WebKit.
The argument for WebKit
To someone like me whose business depends on the Mozilla platform, the biggest argument for WebKit is Mozilla’s large memory footprint. Developing on top of Mozilla has presented many challenges, but most of these can be overcome with time as the intricacies of the platform are mastered. The one that keeps me up at night is the tendency of Gecko-based applications to consume relatively large amounts of memory. My impression is that this is one of the main barriers to continued growth in Firefox market share, since it is of major concern to the digital cognoscenti who drive the technology choices of their friends and family.
Some of this is due to the way Gecko represents webpage DOMs in memory, some of it is a result of Firefox’s rich extension mechanism and some stems from the uneasy relationship between XPCOM and JavaScript. Like any software engineering issue, this could be solved with sufficient development effort. By all accounts, however, WebKit has a significantly smaller memory footprint, so its adoption would be the surest way to address this issue.
A direct consequence of Mozilla’s larger memory footprint is the difficulty of getting Gecko-based browsers to run on mobile devices. We’re witnessing a major shift in the center of gravity of browser usage from the desktop to portable devices. It is safe to assume that an ever increasing proportion of people’s browsing time will be spent on cellphones, PDAs and the like. Mozilla is facing irrelevance in this new territory as stakes are claimed by WebKit and Presto (Opera’s rendering engine). Once again, WebKit has amply proven its viability on mobile devices, most notably on the iPhone.
A less tangible benefit of dropping Gecko in favor of WebKit would be the pooling of community resources that would result from a rapprochement of the Mozilla and WebKit communities. There’s lot of work to do in the web browser space as web technologies become general-purpose software application technologies (a direction that Apple clearly supports):
- Local caching of code for offline operation
- A flexible storage API backed by a proper database engine
- Real-time rendering of 2D and 3D graphics
- Better forms with native widget support
- Strong online identity backed by digital certificates
- Application integration
- Peer-to-peer networking capabilities
- …etc…
Much work is underway to address these lacks, by Mozilla, Apple, Adobe, Google, Microsoft and other major industry players. Mozilla will achieve broader adoption of whatever solutions it opts for in these areas if it joins forces with Apple and Adobe (the latter uses WebKit as the rendering engine for its AIR runtime platform) and will be able to benefit from the formidable engineering resources of these companies. Some of this can be achieved through participation in industry consortia like the WHAT WG, but this would still lead to enormous duplication of effort. This is not to say that the future of the web will be cooked up exclusively by standards bodies. There will be ample room for organizations to deploy their own solutions and duke it out in the marketplace. But innovation will still occur more quickly if the open source world commits to a single set of foundation components, among which the rendering engine plays a central role.
The argument against WebKit
There are thus obvious advantages if Mozilla switches to WebKit for Mozilla 2, thereby creating an open-source powerhouse with major industry backing to compete with proprietary offers from Microsoft, Opera and others. There are, however, a host of formidable objections as well.
Losing XUL and XPCOM
The most glaring drawback of abandoning Gecko would be the massive porting effort required for applications that depend on the current Mozilla platform. This includes Firefox itself, other Mozilla products like Thunderbird, other high-profile products like Joost and Songbird, and the vast number of Firefox add-ons that depend on XUL, XPCOM and other Mozilla-specific technologies. A partial answer to this objection lies in the fact that Mozilla 2 will anyway break binary and source-level compatibility with existing XPCOM applications. If there was ever a time to make the leap to an entirely new rendering engine, it is now.
At end of the day, choosing the right path depends on correctly assessing the future relevance of XUL and XPCOM. XUL is a visionary technology that was invented to meet a need that few at the time had recognized. It adds application-style markup to complement HTML’s document-centric tag set, including form widgets and a box model that better suits application user interface layouts. Since XUL’s inception, rival markup dialects like Microsoft’s XAML and Adobe’s MXL have appeared, confirming that the void it fills is real. The number of popular applications that use any of these languages is minute, however. Instead, the new generation of hit apps (Zimbra, Gmail, Facebook, etc.) use HTML and JavaScript, with a slew of clever hacks to work around their shortcomings.
It is hard to imagine that either XUL or its rivals will achieve mainstream success on the web in the teeth of HTML’s unstoppable momentum. The participation of Mozilla, Apple, Adobe and Opera in the WHAT WG is a tacit admission of this fact. HTML will be incrementally improved until it is as effective for application markup as XUL is today. The sooner Mozilla accepts this fact and drops XUL, the better prepared it will be to compete in the future world of souped up application-ready HTML. A lot of Mozilla application developers (including AllPeers) will experience some pain as they rewrite their XUL-based UIs, but this task will have to be faced sooner or later. (For this and a number of other reasons, we are already using HTML for much of our UI, and we’re contemplating porting the rest to HTML whatever the future of XUL turns out to be.)
XPCOM is a similar case. It was created to add vital capabilities to C++: clean separation of interface and implementation, runtime type information, cross-language support and memory management. Nowadays, all of this can be had by switching to a more modern implementation language. JavaScript has achieved unrivaled primacy on the web and so is the natural choice. None of this is controversial in the Mozilla world: the transition to Tamarin and JavaScript 2 make up a significant (perhaps predominant) proportion of the work planned for Mozilla 2. DeCOMtamination is a huge priority as well. There is no indication that XPCOM is achieving any adoption in the wider world of the web. The Mozilla wiki says they “won’t drop XPCOM completely,” but one has to wonder whether Tamarin and a C bridge like js-ctypes won’t obviate entirely the need for XPCOM.
Development effort
Mozilla 2 is slated for release in early 2009. It is not obvious to me that a WebKit-based Mozilla could not be produced in this timeframe. In fact, to the extent that switching to WebKit would permit pooling of resources with other big WebKit users to add new features like offline capabilities and graphics support, this might be more realistic than the current development plan. Moreover it would provide an iron-clad guarantee that Mozilla will be a contender as every mobile device manufacturer under the sun races to respond to the iPhone by offering a usable web browser on its products.
Promoting choice on the web
It is Mozilla’s stated goal to promote choice on the web. It is an incontrovertible fact that the demise of Gecko would reduce this choice in some measure. But from the perspective of software developers and end users, web rendering engines are increasingly commodities. The underlying standards are well-established. As a user, all I really care about is that pages are rendered as expected, quickly and without using too much CPU or memory. WebKit appears to meet these requirements at least as well as Mozilla. And if it ceases to do so at any point in the future, the open source nature of the project means that it could be forked with no worse consequences than those arising from the ongoing parallel development of Gecko and WebKit.
Not to mention that there is far more to a web browser than merely an HTML rendering engine. Just as Firefox, Camino and Seamonkey all build on top of Gecko, there is plenty of scope for a range of WebKit-based browsers, the most prominent of which would be Firefox and Safari. Each would fight for users by seeking to improve the browser experience through innovation in user interface design and ancillary services like bookmark management.. Although Apple is apparently playing nicer nowadays with the KTHML community, as well as participating in WHAT WG, it is highly implausible that innovation in web architectures will be driven forward primarily by standards organizations and their proprietary rivals (Microsoft, Google and Adobe, with Sun playing a peripheral role). There will be plenty of scope for Mozilla to add value in the web space by designing and implementing solutions for offline access, persistent storage, interapplication communication, desktop integration, social and e-commerce features and the like.
Conclusion
I’ve spent the past six months thinking hard about the future of applications. My conclusion is that desktop-enabled web applications, epitomized currently by WebRunner, will eventually win out. Moreover, I am convinced that Apple has made a brilliant strategic move by recognizing this trend and committing to it in the face of brutal criticism by outspoken technologists.
Innovation in this new area would be accelerated considerably if the open source world were to adopt a standard architectural stack for the web client, analogous to LAMP on the server side. The most logical choices for core components of this stack are WebKit, Tamarin and SQLite. Mozilla is already committed strongly to the last two items. The clearest statement that Mozilla could make to indicate that it has its finger firmly on the pulse of current web trends and intends to face head on the proprietary challenge posed by Silverlight, Flex and Java FX would be to build a rich Mozilla framework around WebKit in the Mozilla 2 timeframe, rather than working to address Gecko’s current weaknesses with an ambitious overhaul.
UPDATE: Some more thoughts here.
48 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>
Speaking as someone who’s done a bit of WebKit development work, and is overall a huge fan of the engine, I think Mozilla should stick with Gecko. Even aside from the (significant!) technological benefits, such as still being able to use XUL and friends, the need for choice and competition in the browser market is demonstrated all too clearly by the stagnation it faced earlier in its history.
So please, Mozilla developers, keep going! Try to kick WebKit’s butt! It’s the only way we can be sure things will keep moving forward.
Comment by David Smith — 10/5/2007 @ 6:20 pm
This has been thought about in the past. roc’s blog has some thoughts on it, last I checked.
I think you missed at least one major drawback: inability to make decisions as needed due to having to coordinate with other webkit stakeholders (e.g. Apple). Of course forking the code is an option, but if the disagreement is on a fundamental architectural level, forking and changing arch is just as hard as changing Gecko.
The other thing to keep in mind is that the Mozilla 2 timeframe does not necessarily foresee huge changes in the layout engine itself. It focuses on changes in the scripting layer and in xpcom. You’re suggesting that both be thrown away in favor of webkit, right?
Comment by Boris — 10/5/2007 @ 6:23 pm
I’m curious as to what tests you have that show WebKit having a significantly smaller memory footprint? I ask because there don’t seem to be any really good apples-to-apples reproducible tests for real-world browser memory usage that I’ve seen. We test Firefox for memory usage while loading static pages via talos - but that doesn’t account for users interacting with AJAX applications over long periods of time. Doing a quick and dirty informal test logging into gmail, google reader, and loading cnn.com on a 2GIG Vista system I get:
IE7: 86.5MB
Safari3: 78.7MB
Firefox2.0.0.7: 53.9MB
If I look at Working Set Size in the task manager. Not saying you are wrong - just wondering how we can get reproducible, accurate, quantitative tests to measure. My informal test isn’t great because all three of those apps change over time, so if I re-do it in 10 minutes the results will be different. Also doesn’t account for many hours of usage.
Comment by schrep — 10/5/2007 @ 6:46 pm
Given how central Gecko is to the entire Firefox codebase, what you’re suggesting is a complete rewrite of everything except the rendering engine.
At best, at the end of the effort you would have something similar to Safari, and lacking in all the features that distinguish Firefox. And you’d lose two years worth of time that could be used to implement better SVG support, HTML 5, etc.
Needless to say, I think this is a horrible idea. It would be more productive to spend the next couple of years tying to reduce the footprint of Mozilla, which I believe is being done. Obviously there are other priorities as well, which means it isn’t going to happen at the pace you might like, but I expect Tamarin and the streamlining of XPCOM will go a long way to decreasing the footprint.
Comment by Ami Ganguli — 10/5/2007 @ 6:48 pm
I think that you should add XBL to the list of arguments against WebKit. Now if webkit adds support for XBL2, it will be a killer platform with not much technical advantages for mozilla IMHO.
Comment by Fabrice Desré — 10/5/2007 @ 6:50 pm
Boris - I couldn’t find anything on roc’s blog about replacing Gecko with WebKit. If you have a link, I’d be very interested to take a look.
As far as coordination with Apple is concerned, part of my hypothesis is that major changes to the core rendering architecture will be less important in the future than work around the edges, where Mozilla is going to be forging its own way in any case. At least in my scenario the chances for coordination are increased.
The fact that significant improvements in the footprint are not foreseen for Mozilla 2 is one of the main reasons why I think a switch to WebKit makes sense. I’m not suggesting that the scripting layer be discarded, but rather that WebKit and Tamarin be integrated. If I understand correctly, Adobe has already done this.
Comment by Matt — 10/5/2007 @ 6:52 pm
You missed a couple important advantages of each engine:
* Gecko is significantly more compatible with the web at large than WebKit.
* WebKit, as a rendering engine, is noticeably faster than Gecko (and this is not chiefly due to missing the compatibility fixes from the above point).
* WebKit’s codebase is significantly smaller and cleaner, which makes it easier to understand, hack and improve (which means I see WebKit’s compatibility as easier to improve than Gecko’s speed/footprint).
In general I think it would be better for both Mozilla and the web for Mozilla to eventually EOL Gecko and shift to WebKit, but not only is that sort of change likely infeasible in the proposed Mozilla 2 timeframe (not that many of the other Mozilla 2 goals _are_ feasible in that timeframe…), but I doubt such a switch could ever happen with the current Mozilla organizational structure or personnel.
Comment by Peter Kasting — 10/5/2007 @ 6:52 pm
Fabrice - Apple is a participant in XBL 2.0.
Comment by Matt — 10/5/2007 @ 6:53 pm
Why discount user interface languages that work great right at this very moment (XUL and MXML), for a possible future HTML on steroids? Nifty DHTML widgets aren’t the same thing as a component-based user interface language with binding and everthing else.
From my experience with both, it takes less time to create/maintain/extend a richer user interface with XUL and Flex than it does with HTML.
Comment by enefekt — 10/5/2007 @ 6:54 pm
Schrep - I’m basing my assumption on two things. One is anecdotal evidence. The other is the fact that no one I’ve spoken to has disputed the idea that Gecko is unsuited for mobile devices due its memory consumption (isn’t that why we haven’t seen a satisfying conclusion to the Minimo project?), whereas WebKit is clearly very successful in this space.
I agree that quantitative measurement is vital before doing anything drastic, but certainly there is enough “reasonable doubt” to invest in this measurement. I’m not sure how best to achieve this (a build with an instrumented malloc?) but surfing AJAX sites and then comparing working sets seems like a blunt tool.
Comment by Matt — 10/5/2007 @ 7:01 pm
Enefekt - Yes, it’s easier to develop apps with XUL and Flex, but one of the goals of HTML 5 (as far as I can tell) is to address this. I see HTML winning out because of its huge momentum, as I explained in my essay. And even if it doesn’t, I think Flex has more of a chance than XUL, which is another thing that should give Mozilla pause.
Comment by Matt — 10/5/2007 @ 7:04 pm
Matt - r.e. Mobile - Gecko already runs on the N800 (http://browser.garage.maemo.org/), which has the same amount of memory as the iPhone (128MB). It is frustrating to not have any quantitative data r.e. memory usage, esp when the informal tests I do show the opposite. Peter is right on r.e. code size, but code size does not directly equal runtime memory footprint. Again, not disagreeing that WebKit is impressive in many ways, just not positive this is one of them.
Comment by schrep — 10/5/2007 @ 7:05 pm
I don’t see why a WebKit-based browser has to be anything like Safari in terms of user experience. It’s a judgment call right now, but I think the time saved by moving to WebKit instead of incrementally improving Gecko would leave more time to work on forward-looking technologies.
Comment by Matt — 10/5/2007 @ 7:08 pm
Schrep - I’m not positive either. If it proves to be the case that Gecko runs on mobile devices just as well as WebKit, that would take a lot of the bite out of my argument.
Comment by Matt — 10/5/2007 @ 7:11 pm
Significant reduction in footprint IS one of the goals for Moz2.
Comment by Taras — 10/5/2007 @ 7:40 pm
“the time saved by moving to WebKit”
I couldn’t figure out if your essay was meant to be funny; I guess this statement proofs it.
Comment by gecko20 — 10/5/2007 @ 7:52 pm
Why would Mozilla even want to ever consider switching to WebKit? Gecko is their own developed engine that has a bigger market share and has some terrific features road-mapped for it. If anything, Apple should have taken up Gecko.
Comment by Jon Pritchard — 10/5/2007 @ 8:02 pm
I’m not seeing this parameter in the discussion, but what about licensing constraints? Outside of the technical considerations, is it even legally possible for Mozilla to switch the rendering engine to WebKit? WebKit is partly LGPL licensed, which is not compatible with the MPL (https://bugzilla.mozilla.org/show_bug.cgi?id=236755#c72)
Comment by Sylvain — 10/5/2007 @ 8:26 pm
Gecko20 - is it really that funny? Apple did exactly that between OS 9 and OS X (bringing in an outside technology as its new operating system core).
Comment by Matt — 10/5/2007 @ 9:06 pm
Other things we’d lose or have to reimplement are MathML, the Mozilla CSS extensions, lots of portability, IAccessible2, the whole XUL extension mechanism, XUL templates, XBL, and who knows what else. Correct me if I’m wrong, but Gecko 1.9 already has many of the things you suggest the merger would help Mozilla focus on (DOM storage, offline apps, native form widgets). Not only that, it contains tons of fundamental improvements and refactorings; the Mozilla codebase is being improved faster than ever. Plus, the Oink-based automated refactoring work is almost ready to go. Besides, it would take lots of time and effort for all the developers to learn a whole new codebase.
Then there’s the question of what to port Firefox’s UI to? HTML? How will they reimplement the whole extension mechanism for add-ons? It will take *years* for HTML to evolve into something as powerful as XUL, if it ever does at all. It would be better and less work to add support for XUL to Safari, which I think they might already be interested in doing. The XUL box model might be standardized as well; let’s wait and see what happens.
Collaborating with Apple et. al. on test suites and testing tools (e.g. reftests, fuzzers, etc.) would be good, but there are just too many problems with changing layout engines.
Comment by James Napolitano — 10/5/2007 @ 9:13 pm
I can clearly see tsunami of mobile web usage. There’s no time to switch rendering engine though. Instead, I suggest to keep Gecko and put it on diet to make it more suitable for mobile use (will you use tabs on VGA LCD of your phone after all?). When the mobile web fad fades away and a new generation of portable PC’s comes to live, Mozilla 2 will be just ripe for that task.
Comment by funTomas — 10/5/2007 @ 9:18 pm
So, once the dust settles, what advantage would the new Mozilla have over webkit? If you think webkit is heading the right direction, why not simply advocate that all mozilla devs jump ship and start working on webkit?
Comment by starwed — 10/5/2007 @ 9:35 pm
Starwed - because there’s much more to Mozilla than an HTML rendering engine. For starters, I would expect a WebKit-based Mozilla browser to be entirely open source and to run equally well on a range of platforms.
The thing I appreciate most in Firefox is the extension mechanism, but I believe that the best approach will evolve over time from its current form. Mozilla is perfectly placed to continue innovating in this area whatever code ends up painting stuff on the screen.
Finally, of course, as with any project the team is more important than any code, and in the case of Mozilla there is a fantastic community supporting it. I wouldn’t want to switch to WebKit unless it had the entire weight of this community behind it.
Comment by Matt — 10/5/2007 @ 10:42 pm
The problem with XPCOM is that people got so excited by this “abstract interface” business that they felt like everything should be abstract, and now there’s this huge mess.
Such APIs should be restricted to the areas where you actually reasonably expect there to be extensibility. Keeping interfaces simple is a good design practice, but foisting an overly complex system that tries to enforce this on a huge codebase is a mistake.
It seems like one of the main areas where XPCOM is used is the reflection of C++ object interfaces into JavaScript for use in XUL.
My problem with XUL is that it doesn’t seem to be going anywhere. Context: It was developed as a way around a Netscape management decision that its engineers would only build one product, so that would be either Windows or something cross platform. The toolkit that was built was developed based on the needs of a web browsing app, which leaves it lacking in some areas where people may wish to build other kinds of apps. Also, from a visual perspective it is an effective way to build a web browsing app for 2004, but with the rich visual environments offered by desktop oses these days vanilla XUL apps beginning to look a little plain. The API is large and often awkward, which is true of many toolkits, but it seems like XUL has not made significant strides in areas other than stability and correctness since the XPFE team was disbanded at Netscape. I will be intrigued to see how this changes in the Mozilla 2 world.
Comment by Ben Goodger — 10/5/2007 @ 11:24 pm
Matt, you wrote: “The fact that significant improvements in the footprint are not foreseen for Mozilla 2 is one of the main reasons why I think a switch to WebKit makes sense.” Where ever did you get the idea that footprint won’t improve significantly in Mozilla 2? That’s just wrong.
You continue: “I’m not suggesting that the scripting layer be discarded, but rather that WebKit and Tamarin be integrated. If I understand correctly, Adobe has already done this.” Not quite. Tamarin in Flash is bridged into an embedded Webkit in AIR, but that’s not the same as replacing JavaScriptCore with Tamarin. As everyone with his eyes open has noticed, Tamarin today does not really outperform other open source engines used in browsers on untyped code. This too we are fixing for Mozilla 2, in the context of SpiderMonkey and Gecko — not Webkit.
The high order bit is that the switching costs are terribly high, for all of XUL/XPCOM compat, time to market, opportunity costs. It would be suicidal to take years (plural) off from the market reengineering all of Firefox including XUL and the addons architecture to run on Webkit. So we are not going to do any such thing.
/be
Comment by Brendan Eich — 10/5/2007 @ 11:29 pm
“My impression is that this is one of the main barriers to continued growth in Firefox market share, since it is of major concern to the digital cognoscenti who drive the technology choices of their friends and family.”
Why do you think that is, given that memory is so cheap now?
Comment by Gerv — 10/5/2007 @ 11:33 pm
I have no idea what its like to develop with, but from a users standpoint, webkit has never impressed me. It lacks all the compatibility that makes Gecko useful and its a whole lot slower in most cases too. I agree that XPCOM and XUL are both reaching a point where their usefulness is less clear. But Webkit as a viable alternative to Gecko, and all because you want to run it on your cell phone? You’ve got to be kidding me.
Comment by DigDug — 10/5/2007 @ 11:52 pm
Some quick responses to my old pals among the commenters:
Peter: we talked about KHTML being lean, mean, and clean in 1999 (shaver, dbaron and I did anyway), and ran through two thought experiments: “dump Gecko for KHTML” and “converge the two engines” way back then.
Hyatt’s work on Webkit shows that KHTML in 1999 was woefully web-incompatble, so we would have been in for a world of hurt just on that front — not that Gecko in 1999 was as compatible as it is now, but it did basic stuff such as residual style right (hyatt had to add that to Webkit several years later).
But even ignoring web compat, which you rightly point out is a current advantage for Gecko (declining at what rate? mattering less compared to other competing desiderata how much?), the switching costs are too high.
The switching costs are not an “organization” or “personnel” issue, or even a “community” and “product” problem, although they create those too. The switching costs are exactly a “does Firefox 4 even ship in 2010?” and “do any addons work then?” problem. I’d switch to a better mouse trap if it were all of (a) doable in a major milestone cycle, (b) significantly technically better, and (c) possible without breaking most XUL apps and extensions.
Doing a new browser with an incompatible XUL-like platform and liberal addon support (which Apple will never do in Safari), that uses Webkit as its renderer, is another matter entirely from switching Firefox or other Mozilla apps to Webkit. No one should assume that Mozillans thinking about the future rule such a project out.
Another longer-term project that may yet come to pass is to converge Gecko and Webkit, somehow. It’s not easy to justify at any given step, but the duplication of effort among the projects, and the competition for open source developers, are not cost-free either.
On the third hand, as a commenter pointed out early on here, the Web may benefit more than it pays for having two competing open source renderers.
Ben: XPCOM was a boondoggle for sure, and worse when used in its primitive pre-scriptable form inside the bowels of Gecko (for Mozilla 2, we are deCOMtaminating hard), but both XPCOM via JavaScript and XUL as a platform are thriving in terms of use and breadth, from Joost to Songbird to a thousand addons.
XUL apps and Firefox addons have significant value taken altogether, and we can’t just throw away compatibility and invite all the people who’ve built on the platform to port to a new, shinier, and (without doubt because of its youth) buggier platform. Still, new platforms will emerge and win adherents, so we’re thinking about how to evolve, not just stultify.
The degree to which XUL is stable and not subject to breaking changes is a good thing, but I agree we want to keep improving it, and not just by adding new widgets or layout models to it. We are now poised to standardize flexible box layout in the CSS WG or (if that goes south) the WHAT WG.
Uplifting pieces of XUL to the web standards is another long-term project that Mozilla explicitly favors, even if it reduces any “platform product differentiation” in favor of Firefox over against other browsers with heavier-weight and less open, or non-existent in a cross-platform sense, extension systems and platform features.
Here’s hoping that such standardization helps converge Webkit (which thanks to hyatt has some XUL box layout in its CSS implementation, and a bit of XBL 1 IIRC) and Gecko.
/be
Comment by Brendan Eich — 10/6/2007 @ 12:04 am
Brendan Eich: memory maybe cheap, but high memory usage exposes in one form or another as slowness in firefox.
Oh, and memory isn’t really cheap.
Comment by Diego — 10/6/2007 @ 1:08 am
Mobile devices isn’t thing that can be any important reason to switch from Gecko to any different engine and drop all longstanding (and really great) efforts at all.
Mobile (really _mobile_, modern laptops have quite enough memory and performance to comfortably run Firefox) and desktop devices are just _different_ things that requires _different_ engines, that’s all.
Comment by MT — 10/6/2007 @ 1:23 am
Diego: I didn’t write “memory is cheap” here, Gerv did. The attribution of comment author is under the comment, not over it.
Since you misattributed Gerv’s comment to me, I will take this opportunity to say that memory is never cheap enough. The marginal cost on the device is not just measured in terms of price per SRAM increment, but competition for power and real estate with FLASH for the camera. So I’m on your side, and as I wrote in a comment here, Mozilla 2 will make significant improvements in both code and dynamic memory footprints.
This is a distinction Matt has blurred: static code size is where Webkit shines (even though Gecko does more, not just in Web compatibility but in modules not present yet in Webkit). Dynamic memory footprint is where Gecko can beat Webkit, as schrep’s working set size numbers suggest. We’ve known this for a while. Gecko’s early implementors prematurely optimized memory use, which increased code size (among other things).
Someone please add reproducible measurements here, the attitude is overwhelming the story-telling (of which I’m as guilty as the next guy) and the content-free fanboy-ism. The case for Webkit based on “footprint” is not clear, contra Matt. Beware the chattering classes of the blogosphere!
/be
Comment by Brendan Eich — 10/6/2007 @ 2:35 am
Once upon a time Mozilla was doomed because XUL was considered impractical compared to native widgets in terms of speed because of overhead in it’s design.
These days most people (at least on Windows) don’t even know the UI isn’t really “native”.
I don’t think we should plan for the future to be about todays hardware. Especially in terms of mobile. 12 months ago the iPhones hardware was unheard of in terms of Graphical performance. In another 12 months it will look like a 1st Gen iPod.
I’d hate to make the browser of 2009 for the hardware of 2005. Especially in terms of mobile where the average lifespan is 2 years. Hardware that’s brand new today won’t be in use in 2009. And 2009 assumes it’s a software project that goes on schedule, which never happens.
We’re a matter of months away from the average computer shipping with 2GB RAM (thanks Vista!). RAM is getting cheaper.
That’s not to say optimization isn’t important, or memory leaks aren’t bad… but that you can only give up so much. Switching to WebKit wouldn’t really be a win. It would be giving up all the advantages Gecko has in the assumption that computer hardware stops progressing after decades of exponential evolution.
Comment by Robert Accettura — 10/6/2007 @ 3:09 am
I don’t think I ever blogged about dropping Gecko for Webkit. But I’ve certainly thought about it and it has been discussed inside Mozilla — along with all manner of other crazy ideas! We’re not afraid to think outside the box.
Dropping XUL is beyond the pale. We need it for our addons and app developer community, without which Firefox wouldn’t be Firefox. We absolutely want to evolve HTML to make XUL unnecessary, but even if we succeed there is no point in dropping the XUL syntax. The scope of a Mozilla Webkit project would then involve adding XUL, XBL2, some XPCOM compatibility glue, and other engine features that Gecko has that Webkit lacks.
That might or might not ever happen. It could happen inside Mozilla, but it could also be interesting territory for a startup (more interesting than cranking out another social networking site, for sure). But I agree 100% with Brendan that Mozilla cannot and *will* not take a few years off improving Gecko or shipping Firefox to make such a transition happen. That would be bad for us and bad for the Web.
Another thing to keep in mind is that Webkit and Gecko are not necessarily the last word in browser engines. There are technical issues in each of them that leave a lot to be desired — e.g. advanced layout, security, safety, parallelism.
Comment by Robert O'Callahan — 10/6/2007 @ 3:55 am
By the way Ben G, XUL has come a long way in some ways. Look at what XUL UIs can do now:
– resolution independence
– translucent windows and popups
– improved accessibility
– vector graphics
– rotation, scaling, blending and other effects on UI elements
– text with kerning, ligatures, subpixel positioning
– much improved support for complex international scripts
– video and audio (coming soon)
Okay, none of those required any new XUL-namespace syntax so arguably “”"XUL”"” itself didn’t change, but so what.
Comment by Robert O'Callahan — 10/6/2007 @ 4:48 am
Brendan - I couldn’t see anything on the Mozilla 2 wiki page about reducing memory footprint. Obviously I’m very interested in this work. Is there a link somewhere that outlines plans and current work in that area?
Some solid metrics about Gecko vs. WebKit (vs. other rendering engines) memory usage would be hugely valuable, and if my post does nothing else besides provoking someone into producing them then I will consider it a huge success.
I really don’t know for sure if WebKit is any better than Gecko on any level whatsoever since everything I know about WebKit is secondhand. If it doesn’t offer advantages over Gecko in reality then clearly my whole thesis is highly suspect. Would be nice to quantify this though.
The other issue is the future of XUL, XPCOM and addons, an area I do feel qualified to comment on. I’ll be writing more about this.
Comment by Matt — 10/6/2007 @ 8:03 am
Matt: the Mozilla 2 automated deCOMtamination patch work (see tglek’s and bsmedberg’s blogs and the relevant bugs) is all about footprint — code footprint, which you again fail to distinguish from dynamic memory footprint for a given workload. Schrep’s numbers show dynamic memory footprint favoring Gecko, for one particular workload.
We are benchmarking all sorts of things, via the “talos” system and buildbot. John Resig’s JS benchmarks, blogged about at http://ejohn.org/, are being hooked up so we can get continuous coverage and regression alarms — just one example, and I’m not going to announce “winner” or “loser” numbers here, or in any blog.
Benchmarking is unglamorous hard work when done carefully, with valid workload reproduction, good signal to noise, and continuous coverage automation — instead of in headline-grabbing marketing claims about “fastest browser on the planet”. We have often had to invent our own benchmarks, since so many bruted in blogs turn out to be hilariously buggy and bogus.
It’s true that Webkit source is smaller than Gecko, in a cut-down apples-to-nearly-the-same-sized-apples comparison. Part of this is the XPCOM tax, which we are eliminating for Mozilla 2.
Thus compiled code is less affected than source, and Gecko has more complex memory-saving algorithms, for better and worse (as I noted, some of these were early premature optimizations), better if you confirm schrep’s working set numbers for yourself and care about that kind of “footprint”. Neither kind of footprint puts Gecko beyond the pale for iPhone class devices.
Also, web compatibility does crud up code, source and compiled, in non-trivial ways. Webkit has grown over time due to web compat fixes, although I’m not sure how much compared to Gecko. Measuring the code size cost of web compat is harder than you might think, since it is usually burned into the source without ifdefs or the like.
There’s no last word here, and the race goes on. But don’t you think it’s a little odd that your thesis depends on measurements you haven’t made, which are not as clearly one-sided as you seem to think?
/be
Comment by Brendan Eich — 10/7/2007 @ 7:09 am
Brendan - Thanks for the clarification. I am definitely looking forward to seeing the fruits of this work, and I’ll be more than happy to eat my words when Gecko starts to emerge as a major browser engine for mobile devices.
> But don’t you think it’s a little odd that your
> thesis depends on measurements you haven’t made,
> which are not as clearly one-sided as you seem
> to think?
No, I don’t think this is odd. I never claimed to be basing my piece on quantitative measurements. I continually hear and read complaints about Firefox’s memory usage. I’ve also observed that Opera and WebKit are kicking our butt in the mobile device space. Both of these might be due to something other than the technical characteristics of the various browsers (and their rendering engines), but I felt there was enough smoke there to at least hypothesize the existence of a fire.
One major reason I have comments turned on is so that people can set me straight if I make factual errors. I really appreciate you taking the time to make a detailed counterargument here. I’ve learned a lot from this discussion.
Comment by Matt — 10/7/2007 @ 8:10 am
Mozilla basically *is* Gecko, it is the main code part. Firefox is just 10% of the code, or less. You link to an article which says “never do a rewrite”, but what you propose means a complete rewrite, no stone left on the other.
I am doubtful that porting XUL on WebKit would be a success, without major rewrite of apps and extensions. A lot depend on strange characteristics and features, not to start with XPCOM modules that most serious apps need.
If you think WebKit is better idea as basis for Firefox, I think you’re better off creating a new project to write a Firefox-like browser based on WebKit. Again, the rendering engine is 90% of a browser, so this is very much doable to do the 10% with only a few persons.
Comment by Ben Bucksch — 10/7/2007 @ 2:21 pm
Note: I think it would be a great idea to have a nice, popular OpenSource browser based on WebKit. I may even use it myself. Konqueror is too much a part of KDE to be a real browser for my taste, and Safari is proprietary.
I like innovation and freedom. That’s why I think there should be many popular browser engines. Too many eggs in one basket are always risky, even if the basket is OpenSource.
Comment by Ben Bucksch — 10/7/2007 @ 2:44 pm
Ben: Swift is based on WebKit, and it’s GPLv3. Currently. It’s based on Qt and C#, so it should be portable (current build seem windows only). Shiira is another opensource browser (BSD license), but it’s Mac only (Cocoa widgets).
Comment by Kim Sullivan — 10/8/2007 @ 4:49 pm
> I’ve also observed that Opera and WebKit are
> kicking our butt in the mobile device space.
Matt, I’d be interested in seeing the data source for this, or how you drew this conclusion. This data says that currently mobile use of the web from any browser is almost un-measurable. http://marketshare.hitslink.com/report.aspx?qprid=0
There are a couple of billion mobile devices with web browsers out there, but none has demonstrated enough utility to users to get them to pop for $40 per month unlimited data plans, and increase mobile use of the web in some measureable way. Its still the very early days of mobile web and a lot of problems need to be solved with data plan cost, device improvements, web site compatibily, and browser technology before the any truly kick butt combination really has an impact on mobile use of the web. Even the iphone, and the plan to ship 10 million units this year might not show up on the radar of use of the web from mobile devices.
Comment by chofmann — 10/8/2007 @ 9:39 pm
Chofmann - once again, the evidence is anecdotal. I know that Opera has been successful on series 60 devices (and on the Wii), and Apple obviously has a great deployment of WebKit on the iPhone. Meanwhile, I haven’t seen Gecko running on small devices.
If I’m wrong and Gecko runs great on mobile devices, then I would be the first to rejoice as this would eliminate the biggest argument (to my mind) for switching to WebKit. I’m looking forward to seeing Firefox on cellphones in this case!
Comment by Matt — 10/9/2007 @ 9:41 am
I’m not sure what you mean by Gecko on mobile devices but if Maemo on the N800 counts, then please give that a try:
http://browser.garage.maemo.org/
Comment by Gen Kanai — 10/16/2007 @ 7:56 am
Hey Nokia, send me a trial unit and I’ll give it a full review!
Comment by Matt — 10/16/2007 @ 9:47 am
you didnt mentions apples horrible treatment of opensource. Apparently its improved but i still dont trust apple after what was basically khtml is now called webkit mainly because they didnt present changes in reasonable sizes. also darwin and Opendarwin dont give them a good track record!
Comment by Xbehave — 11/30/2007 @ 8:22 am
FF3’s looking pretty good.
Comment by John — 3/16/2008 @ 2:44 am
ok,good!
Comment by powerlin518 — 3/22/2008 @ 1:53 pm
I personally wouldn’t mind it at all if this were to take place. Two reasons:
• My web development would be made a little easier. Although most things render the same way between Webkit and Mozilla, there are some odd little annoying things here and there that have to be dealt with.
• XUL-based apps make my Mac cry. Honestly, it’s pretty sad - Firefox and Thunderbird feel so slow, clunky, and alien on Mac OS it’s not even funny. Though they tried (a little) to remedy this in FF 3, it’s not much better either.
Comment by John Wells — 3/28/2008 @ 2:31 am