Have you ever wondered why there is so much differentiation in all the various browsers based upon the WebKit [engine]?
I must admit, I haven’t given it that much thought, but after reading an article in InfoWorld, I must admit I was not fully in possession of the facts. (as an Opera user, I think that the speed that is being pushed by WebKit browsers is great, but the interfaces all leave me fairly cold, so I leave it there). I have gotten SRWare’s Iron installed on 2 of my machines, so that I have a second opinion handy, if I happen to need one.
But, I have not used Safari for Windows since the first beta of release 3. It was fast, but I hated the look and feel, so I quickly removed it. Nor have I used any of the smart phone versions, which may be based on the same code, but of course the interface is quite different by design. I know that the version 3 of Maxthon is WebKit based, but earlier versions of it left me underwhelmed, so I have little hopes for any new version.
The last paragraph might have seemed to ramble, but I made the references to show how different the browsers can be, and that WebKit is not a look, it is an engine, in the same way that Doom and Quake share the id engine with other games, but the look and feel is not much more than mildly the same.
What the article speaks to is how different the implementations of WebKit can be, and that all the results, from differing implementations, are not necessarily good.
Pointed out is the fact that, unlike some other ‘standards’, there really is not one for WebKit , so its use does not guarantee a look or even good results on tests.
Last week I wrote about the benefits of open standards versus open source. I argued that open standards provide greater protection against vendor lock-in than open source alone. I was reminded of this conclusion when reading Peter-Paul Koch’s analysis of WebKit implementations. Thanks to Palm’s Dion Almaer for pointing out the analysis.
Readers know WebKit as the open source Web browser engine used by several mobile and PC Web browsers, including Apple’s Safari, Google’s Chrome, Palm’s WebOS, and the Android Web browser. In fact, Wikipedia lists 19 browsers based on the open source WebKit browser engine. As you read on, keep in mind there is no standard that vendors using WebKit must adhere to or claim certification against. A WebKit-based browser is, well, whatever the vendor wants it to be.
[ InfoWorld Test Center named WebKit one of the best open source developer tools in 2009. Find out why. | See what other products nabbed a 2009 InfoWorld Bossie Award. ]
When Koch tried out WebKit browser versions on 27 tests, he found:
• Out of 19 tested WebKits, no two are exactly the same.
• The best WebKit available is Safari 4; the worst is S60v3.
• The Android G1 and G2 WebKits score rather badly; it’s the worst mobile WebKit except for S60.
• Regressions are fairly common: iPhone 3.1, Android G2, and S60v5 all (partially) dropped support for features handled by their predecessors.
• The closest relation of a desktop WebKit to a mobile WebKit is between Safari 3.0 and S60v5. I’m now fairly certain S60v5 is actually based on Safari 3.0. Unfortunately, this is the single example of such a close relation.
Koch’s testing highlights two truths. First, pity the developer whose manager or customer expects that the application will work on multiple mobile browsers “built on WebKit.” Second, open source does not make it easier for customers or their developers to transition applications from, say, building for the Google Android platform to, for example, Palm WebOS.
Imagine if there were a WebKit standard and a compliance test suite that vendors had to certify against to use the WebKit brand. Customers and developers would gain protection against vendor lock-in that open standards deliver to a much higher degree than open source alone. I’m not naive enough to think that open standards equal “write once, run anywhere.” But even if a WebKit open standard could drive a 50 percent improvement in compatibility across WebKit-based browsers, that would be something to write home about.
I find it interesting that there is such deviation, because, when many people, only faintly familiar with programming hear WebKit, they think Chrome. If they are Mac savvy, they might think Safari, and they know those two browsers are lauded as being fast.
Unfortunately, that is where a lot of the sameness ends. According to the information in the article shown, it is not the only place where differences lie.
For those choosing a browser, it will always be a matter of choice, unless, as in the case of Internet Exploder 6, it happens to be dangerous. But the people at Google took care of that with Chrome Frame.
It would be nice if we could put browsers together ourselves, like Legos, but alas, such is not the case. Until then the choices between raw speed, user friendliness, and safety will dominate the conversation, and be a part of each user’s selection.
§
•
~~