Skip navigation

HTML 5 and the Future of Silverlight

Recently I sat in Redmond, WA at Microsoft headquarters for one of the councils I serve on and listened with absolute fascination to Brad Becker (Director of Product Management, Developer Platforms) and Brian Goldfarb (Director, Developer Platform Product Management team) honestly and candidly describe the challenges, opportunities, and confusion the HTML –Silverlight “thing” has created.

“In about half the time HTML 5 has been under design, we've created Silverlight and shipped four major versions of it,” said Brad. Brad was the product manager for Flash and Flex at Adobe before taking his role at Microsoft. He has a career and reputation rooted in rich client applications for the web.

 The Reality

The reality is that, even though the major browser platforms already have HMTL 5 implementations in beta (including Microsoft’s IE9), the specification for HTML 5 is not even close to being completed/ratified. It could be years. Adoption could be years after that. So why all the hysteria? Is it just the technology industry that gets sucked into hysteria situations like this? That latter question is rhetorical, but the reason for the hysteria is that HTML 5 offers a bold promise of rich client applications for the web that are ubiquitous among browsers, platforms, and devices. And we are clearly in HTML 5 hysteria right now. Do a little Internet search on HTML 5. It is shocking. The other reality is that even when HTML achieves ubiquity, and it will; it still will not measure up to Silverlight. It won’t measure up to Silverlight 4 and God only knows (although there have been a lot of hints) at what version 5 of Silverlight will feature. For instance, arguably the biggest and most exciting feature of HTML 5 is the video tag: <video>. The video tag will allow the developer to simply embed video playback directly in the HTML. “The media features of Silverlight are far beyond what HTML 5 will provide and work consistently in users' current and future browsers,” said Brad Becker. What Silverlight does now and HTML 5 will not do is:

  • High Definition (HD) H.264 and VC-1 video
  • Content protection including DRM
  • Stereoscopic 3D video
  • Multicast
  • Live broadcast support
  • (Adaptive) Smooth Streaming
  • Information overlays / Picture-in-picture
  • Analytics support with the Silverlight Analytics Framework

And the video thing is just one use case. I could go on and on, with arguments rooted in developer productivity and data access and such, but the point here is you cannot compare HTML 5 to Silverlight. It is not fair to HTML 5 to do that. For that matter you cannot compare HTML 5 to Flash for many of the same reasons.

 

 

 

 The Problem

The real problem is that today we have completely different implementations of HTML 5, and we will for a long time. With excitement, a few weeks ago I installed IE9 because of its HTML 5 implementation. Once I installed it, I marveled at all the cool demos and HTML 5 apps at http://ie.microsoft.com/testdrive/. Then, for kicks I went to the same sites in Safari on the Mac…yikes. Then I went to the same sites in a HTML 5 implemented browser on Windows that is not Microsoft—even worse! Then I suffered the next two weeks with all the Windows client applications I use that embed a browser control which were now broken. I really underestimated the pervasiveness of the browser control in the Win32 and WPF applications I use that are now all broken because of my IE9 installation and consequent incompatibility with HTML 5. Two examples are my United Airlines timetable application and my Verizon cellular modem application—both broken by IE9 because of the embedded browser control’s incompatibility with HTML 5. I’m glad there is an uninstall for IE9 or else I would have had to wipe my box and start over.

But, are we really headed back to the days of 1998 where we had to fork the code base for every one of our web applications and web sites? Where we had 3 different versions of every web application we built because each of the three main browsers behaved differently? A decade ago, we used to have to do a browser sniff to determine which codebase to run, and we had to maintain 3 codebases. I do not want to relive that. But, the iPad has forced many to do just that: the Flash or Silverlight version and the non Flash or Silverlight version. And with HTML 5 looming, it could . . . I mean it will, get even uglier. Even though ubiquity is the bold promise of HTML 5. Until all the browsers implement HTML 5 with some resemblance of parity it is going to be an incompatibility nightmare. And that incompatibility could last for years. Over a decade ago I worked on that server product team at Microsoft which was Microsoft’s very late entry to the Internet. I really don’t want to live that pain again.

Consistency between implementations of HTML and CSS has always been a challenge. And because of this, these technologies have traditionally had a lot of issues with variation between browsers. Therein lies the problem. It’s like we can see the tsunami coming and have plenty of time to react, but we won’t be able to.

It is interesting (and encouraging) to me that HTML 5 intends to adopt features as standards which were innovations first introduced by browser plug-ins like Flash and Silverlight. But another reality of the situation is that the solution architecture decision by which we decide how an application is manifested has become harder. Explaining why “it’s a Silverlight app” as opposed to an HTML 5 app to a CIO/CTO that has been sucked into the hysteria is even harder. Trust me. I have already been there and already failed.

For more details on Microsoft’s position on the HTML 5/Silverlight thing, I strongly encourage you to read Brad Becker’s blog post titled “The Future of Silverlight.” It is very well written and really helped to clear things up for me. Articulating Brad’s vision, the reality of the HTML 5 situation and explaining it to technologists who have succumbed to the HTML 5 hysteria is a totally different challenge for me.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish