Last week, Apple CEO Steve Jobs published a bizarre public letter in which he attacked Adobe, one of his company's biggest partners. His charges against Adobe were many, and Jobs spared no ire in his description of Adobe's cross-platform development tools which, heaven forbid, would allow developers to more easily create applications that would run on competing platforms as well as they run on Apple's iPhone. I could write pages and pages of text criticizing Jobs for this strange outburst. But one part of his letter really hit home for me, because it touches on a topic I've been mulling over for months. And that topic concerns no less than the future of the web.
This is an important topic because we're moving ever so quickly into a world in which most of the applications and services we consume are delivered via the web. As the web takes the place of traditional Windows applications, developers have new issues to confront around compatibility, connectivity, performance, and functionality. And these issues are aggravated by the fact that the web is an ever-moving, ever-changing target, with standards bodies and the special needs of industry trade groups to deal with.
Today's web is woefully inadequate from a technical perspective, and various parties have sought to improve matters by offering different solutions for overcoming the limitations. For example, companies like Adobe and Microsoft make proprietary runtime environments—Flash/AIR and Silverlight, respectively—that make the web more like Windows. And browser makers are embracing web standards like HTML 5, Cascading Style Sheets (CSS), and so on—although these standards are a mess in the making and are haphazardly implemented from browser to browser.
Apple uses the WebKit rendering engine in its Safari web browser on both the desktop (PC/Mac) and on mobile devices (iPhone/iPod). In his letter railing against Adobe, Jobs said that WebKit is "widely adopted" and that it's used by "almost every smartphone web browser other than Microsoft’s." While this isn't strictly true and doesn't address the more diversified desktop market, he confused matters further by stating that "Apple has set the standard for mobile web browsers." That is, it's not an "international standard"; it's "the standard by which other browsers are measured." (This is like confusing the terms "complimentary" and "complementary.")
I used to believe that rallying around a single web rendering engine made sense, and I had even called out WebKit as the possible "standard" around which this could happen. But as I investigated WebKit and how it's implemented on different desktop and mobile browsers (Google Chrome and Apple Safari use it on PCs), I realized this was a mistake.
The problem is manifold. First, there's no such thing as a single WebKit standard. Each browser on each OS platform implements it differently. Second, WebKit isn't distributed like Microsoft Internet Explorer (IE) is. If you use WebKit in your own products, you're responsible for keeping it up to date, so it's possible that users could have multiple WebKit versions on their PCs, all with their own update mechanisms. Finally, as browsers mature and take advantage of more of the underlying power of the PC (or whatever platform they run within), they can offer more power and functionality. But each browser on each platform would need to be independently developed to harness this power.
I began realizing my mistake about WebKit around the time that Microsoft started discussing its plans for IE 9 last November. At that time, and then again at the time of the public preview release of the browser in March, Microsoft highlighted three main topic areas for this browser version: performance, hardware acceleration, and standards interoperability. But what most of the tech press focused on, for fairly obvious reasons, was the performance. It animated and rendered onscreen objects at a speed that put all other browsers to shame.
I was interested that Microsoft would continue advancing its Trident rendering engine to take better advantage of underlying PC technologies like Direct3D and hardware acceleration. But what really caught my attention was the company's notion of "standards interoperability," which has since evolved to a simpler term, "same markup." The idea is elegant and obvious in retrospect: Every web browser should render the same web markup (HTML, CSS, or whatever) identically. It's not the rendering engine that matters. What matters is that they adhere to a new kind of standard that we don't yet actually have in place.
Today, that's not what happens. And, sorry WebKit fans, that's not what happens within the realm of WebKit-based browsers either. In fact, depending on the sites you're visiting, WebKit-based browsers rendering the web differently to some degree, ranging from subtle to profound. And because WebKit is only part of what makes a browser a browser, the other differences can be even more problematic.
And now that Microsoft has played its hand and announced that it will be adding hardware acceleration to IE 9, competing browser makers will want to follow suit. Good luck, though, because each WebKit browser will need to handle this differently on each OS mobile and desktop platform, effectively bifurcating the WebKit family of products even further. WebKit isn't a standard—it's a mess.
I'm not suggesting that IE 9 is the future of the web. But I am suggesting that Microsoft's plan for "same markup" is the right one. It's the one that the web will need to follow so that, no matter which browser comes out ahead, users will always have a great experience, and one that isn't marred by strange differences between browsers. This plan also leaves room for competitive advantages, where each browser maker can be innovative both within and outside of the rendering engine, adding value as they see fit.
For the web to become the overreaching computing platform, it needs to "just work." And for the web to just work, it needs a set of standards that actually make sense, not the ridiculous current standards tests—I'm looking at you ACID3 and SunSpider—that in no way map to real-world usage. (I've heard such tests described as "juggling in a canoe"—interesting to look at, but ultimately pointless.) Standardizing how browsers handle web markup is a much better plan than creating a single, commodity rendering engine. It maps neatly to the way we expect other aspects of our computing environment—processors, RAM, network cables, and so on—to just work with our PCs, regardless of the make or brand. That it comes from Microsoft is, in many ways, simply coincidental. But it's the right approach. Let's make it happen.
It turns out I'm not the only one thinking along these lines. In investigating this issue, I came across the following blog post, which could prove of interest. It relates only to the mobile versions of WebKit, but basically arrives at the same conclusion: There's no such thing as a single WebKit.
There is no WebKit on Mobile - "Out of 19 tested WebKits, no two are exactly the same."