Almost three years ago, Microsoft came out with Silverlight 1.0. While Adobe may have been sanguine at the time, Microsoft has pushed Silverlight relentlessly, successfully, and with almost nary a mark on Adobe's hegemony, indicating perhaps that there was always room for both. Now, on the metaphorical eve of HTML5, we got Adobe and Microsoft to come debate us and each other, and to talk about the next battlefield: Mobile.

I will frame the debate and a few highlights below, but you can download the audio of The Fritz & David Show, or click the little play button in this sentence. The podcast player should appear as a pull-out tab near the lower left hand side of your browser's window. The Podcast includes, as always, Techweb's Chief Content officer, David Berlind and me, but also Dr. Dobbs Editor-in-Chief Jon Erickson, Microsoft's Director of Developer Platform Marketing, Brian Goldfarb and Adobe's Director of Technology Strategy, Anup Murarka.

I'd like to personally thank both Goldfarb and Murarka, along with the PR folks representing Microsoft and Adobe-- getting on a podcast together, going toe-to-toe is always a risky proposition-- and both companies were immediately game to do it. David and I found that particularly refreshing.

Attracting Developers

Developer mindshare is ultimately what Microsoft and Adobe are battling for. Adobe rides a history that gives Flash almost complete end-user market share: 98 percent of Internet-connected desktops run Flash, Adobe claims, and 95 percent were running Flash 10 within a year of its availability. This is clearly important to developers. Since Adobe isn't in the OS platform business, it has made significant investment in running within every browser and on every platform.

Microsoft, now on Silverlight v4, claims 45 percent penetration, and higher (60 percent) in Europe and Asia. It also runs across platforms and browsers, although it has taken some heat on its slothful support of Linux. It supports Novell Moonlight (any user of any Linux distribution can go to Novell and get Moonlight which will run on any Linux distribution; for free).

Just as important, Microsoft claims a developer community of half a million.

Both have marquee customers. Microsoft will certainly benefit from the current spate of high-profile live sporting events, including the just-concluded Winter Olympics, the imminent onslaught of March Madness (college basketball's annual year-end championship tournament). It also runs the Netflix Watch Instantly service and, my personal favorite, Victoria's Secret Fashion Show. Adobe simply powers most of the biggest web video sites in the world, including YouTube and Hulu (numbers one and two in terms of online video traffic).

We debated these numbers, and what they mean (and how to interpret them), but there's another factor we spent significant time sparring over: the quality and access to developer tools. One of the smartest things Microsoft did when it released Silverlight is to make it instantly accessible to the Windows development community. Microsoft .NET developers could create Silverlight applications (using Visual Studio). Flash uses Actionscript, and Adobe has its own set of tools for building Flash applications (Flex, Flash Builder, and enterprise applications using Eclipse).

Anders Carlsson, an Apple employee, announced today on the WebKit mailing list an evolution of the WebKit project called WebKit2.

WebKit2's major aims are to bake both a "split process model" and a non-blocking API into the WebKit product—and by extension into Safari and any other client which takes advantage of the WebKit2 framework.

Google's Chrome browser launched in late 2008 with what's called a split process model, one in which each WebKit view runs in its own process. This means that when a bad plugin or a bug in the renderer causes an error, only that tab will crash instead of the entire browser.

IE8 has a similar system and Firefox is exploring one as well with Electrolysis. Apple's Safari 4 gained a related feature under Mac OS 10.6, which runs plugins like Adobe's Flash in a separate process and prevents the whole browser from crashing due to plugin faults. WebKit2 validates that approach by building support for split processes directly into the rendering engine.

Out of my way!

Another goal of WebKit2 is to implement the API to the framework in a completely non-blocking manner. This means that developers can hook into API methods with various kinds of callbacks in order to receive notifications from WebKit views.

For example, in my application I might want to load a webpage. I would call the loadWebsite method (which I just made up), pass it my URL, and additionally specify a callback method or block of code I would like to have attached to a particular event—say didFinishLoadForFrame (which I did not make up).

Whenever the webpage is done rendering, my code would be executed or my method called or pinged. This should result in much more responsive applications which hook into WebKit2. Theoretically, while the renderer is rendering something, the main application loop can move on to doing something else as requested by a user.

There are three techniques currently implemented to achieve this goal: notification-style client callbacks, policy-style client callbacks, and policy settings. A fourth method, code injection which can interact directly with the DOM, is proposed but not yet implemented. These are described in more detail on the project page.

The neat thing about Apple's implementation is that these abilities can be used and exploited by all downstream clients of WebKit2, since they are baked right into the framework—in contrast to the tack taken in Google Chrome. The end user of an application that uses WebKit2 will get a more stable product and developers can take advantage of these enhancements without having to implement their own solutions or jump through unnecessary hoops.

WebKit2 is currently supported on Windows and OS X—the two platforms on which Apple deploys Safari. Linux support is not mentioned at this time.