IE and WebKit Performance; Is WebKit the Ralph Nader of Browsers?
Date : 2008 03 07 Category : Tech & Development
Ajaxian
We have seen a barrage of performance and compliance information this week haven’t we. Wow. We got a little more yesterday too.
The WebKit team talked about the Acid 3 test and how they are up to 90/100:
Support for CSS3 Selectors
We added support for all of the remaining CSS3 selectors. These include selectors like nth-child, nth-of-type, last-child, last-of-type, etc. These selectors were already implemented in KHTML, and the KHTML developers had even kindly provided patches for us in the relevant WebKit bugs. Therefore it was a simple matter of taking those patches, updating them to the WebKit codebase, and then merging them in. A big thanks to the KHTML developers for their hard work in this area.
Parsing Bugs
WebKit had a number of minor parsing bugs that Acid 3 targeted. The boxes did not render properly because of an obscure parsing bug that the test exploited (thanks, Hixie). In addition a number of other parsing bugs kept us from completely passing individual tests. We have updated our parser to be much closer to the HTML5-specified parsing rules.
WebKit has also never parsed DOCTYPEs before. I re-wrote WebKit’s DOCTYPE parsing to match the HTML5 specification, and so now if you put a DOCTYPE into your page it will be present in the DOM. In addition many bugs centered around proper mode resolution (quirks vs. strict) have now been fixed. You can document.write a DOCTYPE for example in a new document and have the correct mode be selected.
SVG
Acid3 has many SVG tests. We’ve been hard at work making these tests pass. In particular SVG font support and other aspects of the SVG DOM have been tested. Many of the remaining 10 points are SVG failures. We’ll be working on SVG animation in order to pass the last few SVG tests.
DOM
Acid3 tests a lot of DOM level 2 features, like traversal and ranges. It particularly focuses on the “liveness” of objects, e.g., making sure everything updates properly when you dynamically change a document by adding/removing nodes. Most of our failures in this area had to do with not behaving properly in the presence of these dynamic changes (even though we tended to pass the more static tests).
The JScript team also blogged about JScript improvements including fixing String concatenation.
Prior to this optimization of string concatenation, most developers used Array join operations to achieve the same result. We were aware of this tradeoff and made sure that the Array operations are also optimized. In either scenario, developers will experience significant performance gains.
I would love to see a benchmark of + vs. join() and hopefully see that join isn’t needed anymore. This feels like some of the moments in Java where the verbose code that you wrote to make things faster started to back fire (e.g. String concat too, and object pooling as creating an object became so cheap).
Ralph Nader of Browsers
This is a very random thought. Watching the WebKit and Firefox teams grinding away makes me wonder if one of them is like the Ralph Nader of browsers. Does WebKit take away share from Firefox? I have seen many developers prefer it recently, and a lot use both (myself for one). Having said that, the bulk of users are probably the folk who buy a Mac and click on the browser icon and don’t really care.
Is having the third candidate in the race a good thing? Does competition between WK and FF itself help both projects and spur them on to greater heights, or would it be even better to have a meeting of the minds and merge the WebKit and Gecko teams, at least in a way where they both aren’t optimizing the JavaScript engine etc. Hmm.
NOTE: There is still a lot of room to innovate in the browser itself, but share the low level engines. Maybe it is most to do with personalities. If the teams could work together that would be one thing (and remember Dave H used to work on Firefox), but it not…. then it is obviously silly. What do you think?