So What's the Fuss about Silverlight?
Perception is said to be reality and there has been a lot of speculation recently about where Silverlight is going and what Microsoft's position is. One of the reasons for this is the emphasis on HTML5 at the recent PDC conference. Unfortunately, that has led to talk and fear about the "doom and demise" of Silverlight. As a Silverlight MVP, what are my thoughts about this?
The HTML5 Story
First, let's start with the HTML5 story. It's a great one. I'm a fan of it, and I believe it is going to be a very positive force. The consumer-facing web is an enormous block of real estate that can only be enriched by providing a cross-browser standard that is far more current than the specification is today.
The problem is twofold: I don't think a lot of people really "get" what HTML5 is or does, and are trying too hard to make it solve problems it wasn't intended to.
If you read this post about a similar topic to my own, you'll see a link to this game written in HTML5 that is quite impressive. You'll also read that "It likely would taken about half of that in Silverlight" and that ... here is the kicker ... the developers "dealt with all kinds of browser compat issues."
The Promise: Cross Browser Compatibility
The Reality: Ummm ... Not Yet
Microsoft itself while embracing HTML5 managed to demonstrate some of the problems with HTML5. They showed how their IE9 browser used powerful graphic acceleration to provide HTML5 experiences at a frame rate much higher than competing browsers. I had to scratch my head there, because suddenly I've lost the consistency. It's great that IE9 does this, but what happened to a consistent cross-browser experience? The HTML5 promise falls short when the experience isn't consistent. If I want to reach my users, I have to code to the lowest common denominator and assume they're not going to be runnig this cool new version of the browser!
Just following the posts about audio and video and graphics I can't tell you how many examples I've read also come with which build of what browser it works on. "This only works with x build because of the audio features." That doesn't doom HTML5, but it sends a strong, "We're not quite ready message."
So What did History Teach Us?
Remember that old, ugly, out-dated HTML4 technology that HTML5 is coming to replace? The HTML4 specification appears 11 years ago: check it out yourself. How long is 11 years? It's a long time - it's before my 10-year old daughter was born. With that much time to digest the standard, take a look at the Acid 2 tests and let me know how far we've come for that truly cross-browser experience.
And we think HTML5 will somehow be different?
Again, don't get me wrong ...I like HTML5. I am taking a serious look at it and know it will be a force in the future. But as I tweeted earlier today, I have to ask ... "Will the real HTML5 line of business please stand up?" It's not there.
Oh, and, lest I forget ... HTML5 is markup. It's not a framework. It is popular to compare it with Silverlight, but Silverlight isn't just a way of rendering things ... it's an actual engine that runs business logic, stores data, and much more. I've written an object-oriented database called Sterling that runs in both Silverlight and on the Windows Phone 7 ... how easy would that be to build in, say, HTML5 for relational queries in offline mode?
My point is that I believe HTML5 is compelling for online content and document-based websites, but I'm nowhere near sold on the line of business story (or even the game story - there are some neat games but the frame rates are absolutely horrid compared to similar Silverlight and Flash games ... yes, Flash, I'm talking to you, too).
The Promise: Write Once, Run Anywhere
Do you remember the popular CASE Tools we were bombarded with in the 80s and 90s? The promise was that we could drag and drop some business logic on a service or use a pseudo-language and everything would generate to native languages for various systems and run everywhere. Of course, when we wanted to customize that, suddenly we had to crack open the tool and wade through obscure code and tweak it to behave the way we needed. What ended up happening is that the CASE tools began collecting dust in most cases and we went back to having different teams that would target different platforms. Most large corporations have this today - ever heard of the rivalry between the "Java shop" and the ".NET shop" in house?
One common trend recently is to tell me that HTML5 is going to be GREAT for phone applications because you'll write it once and it will run everywhere.
Do you really believe that?
Personally, my phone browser is fine for rendering 90% of the websites out there today. And I hate it. It is not a good user experience to have to use a pinch gesture to expand the screen and try to avoid accidentally clicking a link and then navigate somewhere and get something done.
Some of these sites are friendly and offer a mobile version. This is great. It makes a lot of sense to me for browsing pictures and flipping through articles. But this isn't accomplished by "write once." They might be using a single technology (HTML) but there are two pages, one for desktops, and one for browsers. That's "write twice."
I helped build a software company that provided mobile device management (MDM) solutions. We had to create clients for various devices such as Windows Mobile, RIM (Blackberry), Android, and iPhone (this was before Windows Phone 7 was released). So we invested a lot of time in looking at the best way to take a line of business application and penetrate the various platforms.
Of course, this problem had already been solved by other companies, and I think everyone would do well to learn from their examples. When I want to browse Facebook on the iPhone, I don't go to the Facebook page. I run an iPhone Facebook application. It wasn't written in HTML. It was written in Objective-C. Netflix has a streaming experience on the iPhone and it wasn't written in HTML either. Their version for Windows Phone 7 isn't HTML5, it's written in my language of choice, Silverlight.
So we ended up doing what most successful mobile shops do. We took an idea, then we had an iPhone team write it for the iPhone, a Windows Mobile team write it for Windows Mobile, a Blackberry team write it for Blackberry ... you get the point.
If there was any "write once, run anywhere" code, it was the service layer. It turns out you can write a rich set of REST + JSON services that are very easy to consume and use across all platforms. That's the cloud coming into play, not HTML5.
Why I'm a Silverlight MVP
If I haven't convinced you that not many well-positioned mobile shops are going to start converting their mobile applications to 100% HTML5 anytime soon, let me share the story from a different angle. I was an ASP.NET developer and was helping build some pretty rich and interactive websites using JQuery, AJAX, and all of the latest and greatest technologies. The only problem was that a lot of companies are still running Internet Explorer 6.0 (yes, even with 9.0 coming out) and compatibility was an issue. It wasn't just IE6, though. Chrome and FireFox all had their subtle ways of "interpreting" the standards and we were burning development cycles trying to create a compelling experience that worked across all browsers (don't even get me started, Safari and Opera).
When I researched Silverlight, it was mainly from the perspective of improving the UI and also being able to truly write the UI once and have it run everywhere. That's all I was looking for and all I expected to get out of it.
Then I wrote the first proof of concept project, and the rest, as they say, was history. I was able to create a compelling experience so fast that my boss didn't even believe me until I demonstrated what I had done. We found it was incredibly easy to train the team and in no time were producing functionality we couldn't even begin to consider using the old HTML technology ... with fewer defects and in about 25% of the time.
You read that correctly. By my best estimate, transitioning parts of the web-based application to Silverlight enabled us to produce 4x what we did before and at higher quality. That is what led me to Silverlight. Frustrated that I had to dig to find this out, and seeing the public perception that it was nothing but a trumped up media player trying to compete with Flash ads, I set out to educate people about the platform through my blog, talks, and other venues. This ultimate lead to the Silverlight MVP award which I am thankful for because of the voice it has given me to share how powerful Silverlight is for serious, enterprise line of business applications.
So Why am I Sharing all of This?
HTML5 is a great technology and it will transform consumer-facing websites. I just don't buy that it is going to be a major player in the line of business world. Perhaps years down the road when standards start to coalesce and more tools are available, but now? The spec isn't set to be finalized until the year 2022. Yes, you read that correctly ... remember HTML4, 11 years ago? That's HTML5, 11 years in the future. Great things will happen before then.
However, I don't believe it is going to replace writing native mobile platform code. Silverlight is alive and well on Windows Phone 7 and will continue to thrive there as Java does on Android and Objective-C does on the iPhone. Let's talk economics - all of these platforms have application stores. Will HTML5 circumvent that? Will the platform truly transform to not need an application store because it's all HTML5? Is your third-person shooter game really going to run just as smoothly in an HTML5 engine? I don't think so ... only time will tell.
Let's forget the mobile side though. We aren't getting rid of laptops and desktops. They're here to stay, and you can't ignore how compelling that platform is for rich applications.
But that is where the playing field is different. Because I'm a Silverlight fan, I'll even use a competitive example: Adobe AIR. I don't see much speculation about AIR going away, when it is a platform for develping rich applications that run on different platforms.
Silverlight shares the same story. With the in-browser experience you can write rich, compelling, powerful applications that easily connect to services and drive user experiences in a short amount of time. I am able to write a fully-styled feed reader application from scratch that interrogates RSS feeds, shows them on an optimized grid and serves links to the sites and stores the data for offline reading in about 20 minutes. I challenge anyone reading this to do the same in HTML5 (and I'm not saying it can't be done - that would be a GREAT example I'll gladly link to when presented).
Silverlight in out-of-browser (OOB) mode is even more compelling. Now I can create a full-fledged application that runs even when disconnected from the Internet ... and here's the kicker: I can easily install it with a click over the web, and I'm confident it will run as I designed it on both a Windows and a Mac. I can truly write it once and run it on multiple targets.
That's a powerful story and I work every day for companies that see the value in that story. So while the speculation out there is that Silverlight is doomed, the project queue says otherwise and the applications you sometimes don't see are the ones driving critical business functions behind the four walls of the corporate intranet.
And the Final Word...
And as a final word, I do have to address the misconception that the PDC event failed to mention Silverlight at all. I heard the word "Windows Phone 7" multiple times, and short of XNA-based games, Windows Phone 7 is practically synonymous with Silverlight. So just substitute "Silverlight" for "Windows Phone 7" and you'll see it got plenty of coverage this go around.
I usually try to focus on technical articles but this is such a large topic that I felt I should share my insights and thoughts. Now I'm excited to hear your feedback as well! Please post comments below.
Jeremy, what's your position?
I believe Silverlight is the absolute BEST choice in MANY scenarios (but not all) and will continue to be a powerful force in the line of business, web-based application arena. I don't think it makes sense to replace web sites with Silverlight, and I absolutely agree that HTML5 is the technology to look at for media, content, and document-based websites and applications ... but for line of business? Give me Silverlight.