Understanding the Microsoft Shift on Silverlight and HTML5

As the old proverb goes, if you can’t beat ‘em, join ‘em. That must be Microsoft’s mantra as it prepares to unveil a new strategy for Windows development at BUILD. It’s hard to fathom that only four years have passed since Microsoft originally introduced Silverlight, but in that short period the world- and Microsoft- have clearly changed. With the rising HTML5 sun on the horizon, Microsoft is signaling a new dawn to its legion of developers.

Microsoft overstepped with Silverlight and HTML5 is the correction. A careful study of Silverlight’s roots makes this clear while simultaneously underscoring the close relationship HTML has with modern Window’s development. No observer of Microsoft history should be surprised by the coming changes to Silverlight or HTML5 in Windows 8.

Let me explain.

The Roots of Silverlight

Rewind your mind to 2003. Windows code named “Longhorn” is generating waves of excitement, showing-off the beautiful successor to XP and promising futuristic new ways for storing files and… a brand new Windows graphics subsystem, codenamed “Avalon.” Avalon eventually progressed to what we know as WPF, but what you may not know is that Avalon’s roots are actually in the web.

Prepare to have your mind blown.

Michael Wallent is not a name you may recognize, but you’ll definitely know the products he has been responsible for during his tenure at Microsoft: Dynamic HTML (IE4), IE5 & IE6, WPF, and ultimately the roots of Silverlight. His background with Internet Explorer and HTML are supremely interesting when overlaid with the foundations of WPF (aka Avalon).

In what should be required viewing for anyone looking to understand Microsoft’s Silverlight story, Michael expounds on the background of Avalon to Tim Sneath in 2006. From the Channel 9 video (emphasis mine):

Michael: “So we finished-up with IE6 in 2001 and we had this real choice: this ‘web-thing’ is really taking-off and we want to make sure we build a platform for that. But we’re not really sure Trident (IE) is going to do it for [Microsoft] because of the scalability issues. And because the programming model between [JavaScript] and C++ is dramatically different and fraught with security issues. And [Trident] just doesn’t scale to meet the problems we needed to solve. It doesn’t do a great job with media. It does an okay job with UI stuff. But we felt in many ways we were limited with [what we could do with Trident].”

“So we said, “Hey, we’re going to start this new project, code named Avalon.” We started it towards the end of 2000, beginning of 2001 to try to build a web client platform that was a follow-on to Trident, but something that was modern that we could really build Windows on top of, not just “dancing hamster” websites.”

Wait, what? That’s right! The roots of WPF are in a project that originally aimed to create a new, modern web client that Windows could be built on. HTML5 in Windows 8 is already sounding less crazy. More from the interview:

Tim Sneath: “When you started Avalon, was that really your goal to replace or supplant the web as we know it today? Or was it a contextual background [for the project]?”

Michael: “You know, “replace” is such a nasty word. I think what we were looking at at that time was that people wanted to build richer applications. And there wasn’t really a good way to do it. HTML is great for a lot of stuff. Nobody loves HTML and dynamic HTML more than me…but the fact is, there are some types of applications that you see people today where they fall off a cliff…what can we do to create a better seamless experience?”

“I think the market recognizes that HTML is good for some stuff, and then to go to the next step, you need other runtimes, because these HTML runtimes, coming from their SGML background, only can do so much. And you can’t push them too far or you’re not going to get a great user experience.”

Okay…so Avalon didn’t exactly aim to “replace” the web as we know it, but it clearly had the ambitions to take the web further. In fact, Michael goes on:

Tim: (paraphrasing) To go back to the genesis of Avalon, how did it incubate from that stage of recognizing the problems with HTML to a team of 100?

Michael: “Basically what happened is that we had a set of really smart folks working on Internet Explorer, and another set of smart folks working on the internals of Windows itself. And we merged those two teams together to create the Avalon team. So we thought it was the best of Windows, best of the web.”

And the veil continues to lift. The roots of WPF (and ultimately Silverlight) are in a project that literally merged Internet Explorer devs with Windows client devs, with heavy influence from HTML. And who had to bless this radical new “integrated platform” (Web/Windows) approach? Who do you think? From the video:

Tim: “Who did you have to persuade to build this team? What kind of buy-in did you have get internally to turn this in to a reality?”

Michael: “Basically, Bill [Gates].”

Tim: “You went and pitched him?”

Michael: “Many times. Many times. We effectively had a charter when we merged the Trident team with the User and DUser teams together to build the Windows platform.”

That explains (in part) why there were no new versions of IE for five years after IE6. It also underscores how significant this new “integrated” (web and Windows) platform decision was 10 years ago. It required approval from the top.

Digesting the Avalon Background

What do we ultimately learn from the Avalon interview with Michael:

1. Avalon (and in turn WPF and Silverlight) has strong connections to HTML and the web
2. Avalon was created because IE6-era HTML couldn’t meet the needs of Microsoft to build Windows (especially around media)
3. Avalon was hugely impacted by Microsoft’s new (at the time) bet on managed code (.NET), which is one of the primary reasons Avalon did not use XHTML for markup.
4. Windows, at least in concept, is built on an “evolved” web client platform

Bottom line: The Windows we know today already is heavily inspired by the web and HTML. The idea of Windows 8 integrating HTML5 for Windows development is nothing new. It’s just a new take on a 10-year-old concept.

The Silverlight Connection

When Avalon became WPF and shipped with Vista, Microsoft ushered in its rich new “evolved web client” platform for Windows development. That made sense.

Then Microsoft introduced WPF/e (e = everywhere), aka Silverlight. What started as a “merged” platform that combined the “best of the web with the best of Windows” was coming full circle in Silverlight and preparing to (in Microsoft’s view) replace the web as we know it (borrowing Tim’s words).

But the web of 2007 was very different from the web circa 2001 that inspired the roots of Silverlight. Browsers were evolving again. Standards were rapidly evolving to eliminate long-standing shortcomings. And perhaps most importantly, internet access was beginning to shift from Windows/Mac PCs to a world of multi-platform devices being lead by the iPhone.

Rather than read the writing on the wall and return to the tried-and-true Microsoft strategy of “embrace and extend,” Microsoft plowed ahead with their own custom approach to web application delivery.

Fast forward a few years and we find a developer community confused by the relationship of WPF to Silverlight. We find a Microsoft recommitted to the web via a reinvigorated IE development team. And we find a world where plug-ins are increasingly taking a backseat role to web application development.

Enter HTML5

Imagine how Windows might be different today if HTML5 had existed at the time of Avalon’s design. Given that the creators of Avalon were so inspired by the web, had the web of 2001 looked more like the web of 2011, maybe Vista would have ushered in an even more web-like development model that’s now being assumed to be part of Windows 8. And if that had happened, the conditions that created Silverlight would have never existed.

That’s not to say that XAML would never have existed (though clearly it would have evolved differently). What Michael says is true: HTML is great for some stuff, then other runtimes are needed to go further. Windows still needs its rich, native development environment. XAML provides that, and it will in Windows 8 and probably Windows 9.

What we don’t need is a replacement for the web. Michael knew better than to call Avalon a replacement, and Microsoft has now learned that lesson with Silverlight. Instead, with Windows 8 and HTML5, Microsoft is returning to the “embrace and extend” strategy that has served it well over the years, and re-calibrating what it means to create an OS that merges “the best of the web with the best of Windows.”

HTML5 in Windows is Not Radical

Despite the media and developer reaction to the early Windows 8 discussion of HTML5, the idea of Windows embracing web technologies for native client development is not radical. As you’ve seen in my documentation of Avalon’s evolution, the idea has been floating around Microsoft for at least a decade, and arguably for even longer than that (many of the anti-trust claims against Microsoft revolved around their deep integration of IE in to Windows in the early ‘90s).

Windows 8 and HTML5 are simply a re-focusing of this long-standing strategy, and it represents a “correction” by Microsoft to properly acknowledge HTML5 as the technology for the web, and XAML as the technology for Windows.

Microsoft “overreached” when it tried to make its “native” platform technology an equally suitable cross-platform, cross-device, “web replacement” platform. There are simply too many platforms and devices for Microsoft to attain that position. Instead, in September Microsoft will re-cast XAML as the solution for when HTML5 is just not enough, while simultaneously embracing more of HTML5 for “near native” Windows development.

Telerik Insurance

It goes without saying, but Telerik is insurance for perceived risk in Microsoft platforms. If XAML continues to be the platform that makes sense for your applications, Telerik will continue to be the premiere provider of XAML tools. If HTML5 and JavaScript make more sense for your next generation of “Windows” development, the new Kendo UI framework is worth investigation. Either way, Telerik, to paraphrase a customer, has your back.

Microsoft can’t replace the web, but that’s okay. With renewed clarity on where “native Windows development” and “native web development” meet, Microsoft and Windows 8 promise to usher in an era of clear developer direction and simplified Microsoft development decisions. Ultimately, what should now be obvious is that the “grand shift” Microsoft will discuss in Anaheim is nothing new. And with that perspective, you can start planning for the future with more confidence while Microsoft does a quick “take 2” on merging the web and Windows.