“Someone’s got it in for me, They’re planting stories in the press. Whoever it is I wish they’d cut it quick, but whether they will I can only guess.”
“Idiot Wind”, Bob Dylan, 1974
A couple of lines that seemed relevant to me in all the commentary that I’ve seen since the PDC last week and the buzz over how much or how little was said about HTML5 and Silverlight.
It was interesting (to say the least!) to watch how some fairly innocuous reporting got picked up and then turned into something else by people other than the original reporters who perhaps wanted to promote a slightly phony war between the Silverlight and HTML5 technologies. To me, some of that felt like it was coming from ever so slightly anti-Microsoft folks who have;
- Woken up and realised Microsoft is embracing HTML5 in IE9 ( this was not new at PDC, the previews of IE9 have been around for quite some time although they improve with each release ).
- A mistaken view that Silverlight is, was or was planned to be a replacement for HTML and/or the browser and so is somehow mutually exclusive with Microsoft embracing HTML5.
Short, Sweet and Complete
Bob Muglia has clarified the situation with a post over on the Silverlight team blog. Quotes;
- Silverlight is very important and strategic to Microsoft.
- We’re working hard on the next release of Silverlight, and it will continue to be cross-browser and cross-platform, and run on Windows and Mac.
- Silverlight is a core application development platform for Windows, and it’s the development platform for Windows Phone.
Steve Ballmer has also commented on the situation.
- We will also enable browser scenarios that provide additional capabilities, including Silverlight. Silverlight provides the richest media streaming capabilities on the web, and we will continue to deliver that on both Windows and Mac.
- Developers can build great applications for it (Windows 7)) using Win32, .NET, Silverlight and HTML5.
That should be the end of the story until there’s an announcement about the next version of Silverlight.
Feel free to stop reading at this point if you’re tight for time. No offense taken 
A Longer Version ( my own 2p )
My view’s probably not worth too much stacked up against that of Bob or Steve but that doesn’t mean I don’t have a view and so I thought I’d share some thoughts.
Whilst watching the various discussions going on, it was reassuring to see that the most reasoned analysis came from seasoned Silverlight professionals who understand what Silverlight is and what it’s used for. Analysis from people such as Laurent, Robbie and Jeremy.
My own opinion is something along the lines of;
- Microsoft needs to have great support for the web standards around the browser (i.e. HTML and HTML5).
- Microsoft needs to have additional frameworks for building clients that are more deeply integrated with the platform (i.e. Silverlight / WPF ) than a browser is today or looks likely to be in the future.
and I think there are many, many reasons why that will be the case for the foreseeable future.
From some of the stories that I’ve seen, I think a lot of confusion stems from people not understanding what Silverlight is.
Silverlight is not a replacement for HTML. Silverlight never was a replacement for HTML. Silverlight is a rich internet application technology.
I often feel that a cross-vendor analogy helps in this area and so I want to digress slightly because I do not think that this need for a rich client technology applies purely to Microsoft.
It’s something that seems to be very much recognised by other vendors too…
Digression…
I’m not an expert on Apple’s developer platform but I want to try and draw an analogy with that platform. As far as I understand it when you look at Apple’s developer platform they support both;
- HTML/5 and JavaScript
- Rich Client applications developed with Obective C and Cocoa (Touch)
and no-one seems to struggle with this.
I rarely see pronouncements that Apple’s support for HTML5 means that they will kill off other APIs such as their Cocoa (Touch) API.
Steve Jobs himself has stated very clearly in recent times the importance he ascribes to Apple’s own APIs so I don’t imagine that he’ll go “all in” on HTML5 in a hurry and make it the only way to build iOS and OS X applications. I’m not even sure that those kinds of applications are allowed in the app-store (but I haven’t checked).
If I want to write a website that targets Apple’s devices but also works well on Windows then I’d go with HTML because HTML is the only way I can get true cross-platform reach.
However, if I want to build something more native then I go with Cocoa (Touch) because it gives me richer access to the platform’s capabilities.
You can find some details of why you go down the different routes in the O’Reilly book "Building iPhone Apps with HTML, CSS and JavaScript” and some of the rationale explained there translates over to the Microsoft platform.
I believe that there’s a similar situation with Java and HTML on Google’s Android platform but, again, I’ve never built an app for it so I’m easy to knock over on that if you tell me otherwise.
Regardless, this multiplicity of APIs seems to be common across platforms.
I drew this picture the other day for the Steve Ballmer event that we did in London as a way of trying to capture that idea that Microsoft has a number of client APIs (not all of them on the picture) and that they meet different needs and need to be compared on a number of axes. You could probably do a similar analysis on APIs that other vendors have for their platforms too;
The “tower” of blocks on the right hand side of the picture is meant to imply that there are different ways of targeting the Windows platform and the relative sizing of those blocks is meant to indicate that they offer deeper integration with the underlying operating system and that typically comes by trading off some other aspect of the API.
There are so many different ways to think about these APIs/runtimes for targeting the Windows platform that I think it can become confusing so I thought I’d add a few words to some of the bullets above to try and outline my own thoughts.
Cross Platform, Cross Device Possibilities
If you can do everything you need to do in an HTML/JavaScript based client then you should build one. Pretty much every device out there has a browser that can display HTML, CSS and JavaScript so you get that ubiquity of the runtime.
The same’s true for HTML5. The intention is for this to get adopted pretty much everywhere and so if your client falls within the capabilities of a HTML5 browser then (from the point of view of cross-platform and cross-device potential) you’d go with it.
However, you’d need to factor in some of the other axes that I’ll talk about here because there are trade-offs around HTML/JavaScript and HTML5 just like there are trade-offs around anything else.
Whilst it’s not as far reaching as HTML(5), Silverlight also runs cross-platform to Windows 7, Vista, XP and OS X but doesn’t span out to those platforms like iOS, Android and it is Moonlight rather than Silverlight that reaches out to Linux.
WPF is, of course, a Windows only technology.
Cross Platform, Cross Device Scorecard: HTML (10/10), HTML5 (8/10), Silverlight (5/10), WPF (0/10)
Platform Integration
How much access to the underlying platform does your client application need? Simple examples…
- On the Windows Phone 7, do you need the contacts list?
- On a Windows PC do you need to enumerate the network connections?
- On a PC with Office, do you need to be able to launch Word to do a mail merge?
There’s a million and one examples here – do you need to process touch gestures? do you need control over printing? do you need access to a camera? do you want to be in the system tray? do you need a background service? etc. etc. etc. etc. etc.
My tower of blocks above are meant to indicate that an HTML client gives you very little access to the underlying platform. There’s some things you can do but not so much. HTML5 does add a bit more into the mix which is only to be welcomed.
This means that an HTML client won’t always get you to where you need and if you need more access to the underlying platform then you might consider something like Silverlight.
Now, I appreciate that lot of folks will say “I don’t care about the platform – the browser is the platform and if it’s not surfaced in the browser then I don’t need to do it”.
Perfectly reasonable view. It’s not one I happen to agree with and the software sales of companies like Microsoft, Apple, Adobe and many others suggest that there’s a lot of value in integrating well with the platform and/or device that you’re running on.
Silverlight gives you deeper platform integration than HTML and yet remains in the cross-platform space supporting both Windows and OS X.
A simple example would be video. HTML5 includes the <video/> tag but (AFAIK) the specification does not specify what formats of video a browser should support. You can work around it and I’ve even seen workarounds that involve Silverlight
Beyond that though you get into things like hardware acceleration, streaming, captions, client and server-side playlists and DRM’d content. The sort of functionality that, today, goes beyond the HTML5 specification.
But sometimes you need more than Silverlight can give you.
There’s functionality in Windows that Silverlight does not expose even if you go via the COM-interop route. Simple examples – a system tray application or an application that has multiple windows isn’t really do-able in Silverlight 4.
In that case, I’d look to WPF and build a client on .NET 4.0 as that gets you all of the .NET Framework goodness plus (should you need it) the ability to PInvoke out to pretty much any Windows API – i.e. the whole Windows platform.
Platform Integration Scorecard: HTML (2/10), HTML5 (4/10), Silverlight (7/10), WPF (9/10)
Runtime Deployment
If you’re going to build a client application for a “runtime” ( such as HTML, Silverlight, WPF, Native Windows ) then you need to think about the deployment of that runtime.
1) Is the runtime out there on client devices?
With HTML, it’s an easy answer – “yes”. Pretty much every device out there has a browser that can display HTML and a JavaScript engine that can run code.
It’s harder to say about HTML5 because it’s not yet finished and implementations such as IE9 aren’t finished either so it’s a bit unrealistic to talk about deployment at this point. The netmarketshare site says that about 55% of the world’s browsers today are previous versions of Internet Explorer that do not support HTML5;
that’s going to change over time and especially when those users running on Windows XP which lacks IE9 move to something like Windows 7;
With Silverlight, it’s not as simple as just saying “yes”.
Silverlight supports Windows XP, Vista, 7 and OS X and runs in IE, Safari, Chrome and FireFox but the runtime needs deploying so there’s a barrier there – you have to get the runtime deployed in the first instance.
According to www.riastats.com Silverlight is deployed to 64% of the browsers that the site has captured for its metrics;
so that’s a pretty good place to be after 3 years of releases but, clearly, it’s behind the percentage of users who have a basic browser that can display HTML and JavaScript today.
Unfortunately, I don’t have access to the same version-specific figures for WPF but the official figure is that 2/3rds of the world’s PCs have WPF installed. It’d be nice to be able to quote the versions though to add a little more to this chart;
but it’s worth remembering how many devices that involves as the Windows PC market is “not small” – I think it’s around 1.2 billion PCs so that would mean that a pretty large number of PCs are running some version of WPF.
2) Is the runtime easy to get out there to client devices?
What if your “runtime” isn’t out there? Is it easy to get it installed?
Silverlight is a ~5MB download and a quick install that requires administrator privileges (as to all browser plug-ins) but no reboot of the machine.
WPF comes in two flavours. The ~30MB client profile and the ~60MB full framework. Again, this requires an administrator account and no reboot of the machine for the client profile version.
Different browsers have different installation requirements. The IE9 beta was 19MB of download and requires both an administrator account and a reboot of the machine.
So, there’s not vast amounts of differences between the download & installation here but there are differences in people’s behaviours around the upgrade process…
3) Do users upgrade the runtime when new versions come out?
One of the important questions about a particular runtime is how quickly new versions filter through to users. It’s difficult targeting a platform if you know that your users are on older versions and don’t move quickly as new versions come out.
Silverlight does very well on this – if we look back to that previous picture from RiaStats, 90% of Silverlight users are already on version 4 of the runtime which is only 6 or so months old.
I don’t have version information for WPF so it’s hard to be sure to what extent WPF versions installed onto user’s desktops are fragmented across the versions 3, 3.5, 3.5Sp1 and 4.0.
I know that all Windows Vista deployments started at V3.0 and all Windows 7 deployments started at 3.5Sp1 but I’ve no figures beyond that – it’d be great to get some and I’ll add them to this post if I do.
In terms of browsers, there’s more of a lag. People seem more attached to their browsers or at least have more inertia around updating them. The previous chart suggests that 15% of IE users are still on IE6 which is a relic from 2001 that the IE team are very keen for people to move away from and 10% look to be on IE7 (2006).
That would mean that 25% of browser users are on browsers that are more than 4 years old.
In short, it takes time for users to upgrade their browsers and new versions of the operating system perhaps represent the best way to get new browser versions into the hands of users.
Runtime Deployment Scorecard: HTML (10/10), HTML5 (3/10), Silverlight (7/10), WPF (5/10)
Runtime Agility
How quickly does a client runtime adapt to a changing world?
If a company such as Apple or Microsoft introduces some new concept, how long would it take to get an updated client runtime that incorporates that concept?
As a prime example – it’s amazing to me how prevalent multi-touch user interfaces have become over the past few years.
For a vendor like Microsoft, when new functionality is added to the platform it shows up immediately in the Windows API and then, typically, sections of that new functionality show up in client frameworks like Silverlight and WPF.
As an example – multi-touch support was in Silverlight 3 which shipped in July 2009 before Windows 7 shipped in October 2009.
Multi-touch support was in WPF 4.0 which shipped in April 2010 around 6 months after Windows 7 shipped in October 2009.
These frameworks are being updated pretty quickly as the underlying operating systems gain new capabilities. Naturally, those new versions still remain to be adopted as discussed previously.
By contrast, HTML lives with the standards bodies and represents cross-vendor agreement that moves at a slower pace. That’s not a criticism – I doubt that anyone wants standards that change on a daily, weekly, monthly or perhaps even annual basis.
Now, I believe that this idea of agility also goes hand in hand with the idea of control.
Some folks are happy with vendors (e.g. Microsoft/Apple) being able to define the APIs for their platforms (e.g. Silverlight and Cocoa (Touch)) and other folks would like to stay away from that and stick to what can be agreed via standards.
My own view is that both have their place.
Runtime Agility Scorecard: HTML (2/10), Silverlight (9/10), WPF (7/10)
Runtime Consistency
If you’re building for a runtime then you want to be sure that what you’ve built in your test environment will work exactly the same way in a user’s runtime environment.
There are numerous different browsers implementing numerous different standards on numerous different devices. It’s not surprising that all of those combinations can produce some different results when presented with the same markup.
One of the big themes around IE9 has been the “one markup” idea which aims to try and minimise cross-browser, cross-device inconsistency.
However, if you’re building for HTML today then you have to factor in some inconsistencies (with IE6 being a common whipping boy here) and test for at least the major browsers on the platforms you’re targeting and perhaps produce browser specific variants of your site.
In the long term, HTML5 will no doubt make this a lot better but there are still going to be variations in terms of which vendors implement which features and how they go about implementing those features so that you can ensure that you get a consistent client experience at least within a particular class of device.
For me, the downside of these kinds of efforts is when you see sites like this site which was, apparently;
“designed for Google Chrome”
which seems like the very antithesis of what the standards people are trying to achieve 
This job of determining features is complex enough to be abstracted by libraries like Modernizer to make it easier but it’s still something that has to be implemented and tested.
If you’re building for a runtime like Silverlight then that’s a single vendor solution so it’s tested by that vendor to work the same way on all the supported platforms and browsers.
Differences are either in the platform by design and documented as such or they’re bugs and so you don’t have to write (e.g.) Silverlight code that varies across Internet Explorer 6, 7, 8, 9, FireFox, Safari, Chrome. You rely on Microsoft to do that cross-browser (and cross-platform) testing.
You could argue that some of this sort of compatibility work does come into play when you look cross-device to the Windows Phone 7 as there are differences in the phone/desktop platforms today.
WPF is also on that single-vendor spectrum. Apps written for WPF should work the same way on all systems that have WPF installed although, again, it’s fair to say that hardware capabilities could produce variation (just as they can for pretty much any client that relies on GPU acceleration).
Runtime Consistency Scorecard: HTML (3), HTML5 (TBD!), Silverlight ( 8), WPF (9).
Application Deployment
Application deployment is a headache and it’s one of the reasons why the browser based model of “zero footprint deployment” has been so successful.
If you’re going to write some HTML(5) then you have no trouble deploying your application. You drop the bits on a web server and you’re done.
This is pretty much the same with Silverlight. You drop the XAP on any web server you like and you’re done if the application you’re building runs in a browser. If it runs out of the browser as well then you need to write a little bit of (fairly boiler plate) code in order to get the auto-update experience.
Deployment of WPF applications is more taxing. There are auto-update mechanisms like ClickOnce which I see applications like MetroTwit using but those only go so far in that certain applications can’t be deployed that way and you’re back to requiring a traditional installation which means more work.
Scorecard: HTML (10), HTML5 (10), Silverlight (9), WPF (5)
Developer Model & Tooling
This is a very subjective area. There are millions of developers out there writing .NET code and there are millions of developers out there writing JavaScript and HTML based code.
I’m biased. I like the world of .NET code with its rich metadata that drives great tooling support in Visual Studio and true component-oriented software development. I’ve also grown pretty accustomed to being able to separate out UI from code and make use of tooling like Expression Blend on top of that.
However, I know that’s not everyone’s view and a bunch of folks prefer the dynamic nature of JavaScript on the client-side and a variety of techniques for HTML generation on the server-side.
Developer Model & Tooling: You decide.
Summary
This has been a long post and I don’t expect that many people read all of it or agree with it, it’s just my view.
What was I trying to say?
- Microsoft supports both Silverlight and HTML(5).
- There are strengths to Silverlight.
- There are strengths to HTML and HTML(5).
- I believe there is a need both for runtimes offering cross-platform standards support and for runtimes that have deeper integration with the underlying platform/device capabilities
- I see Microsoft doing this with HTML(5), Silverlight, WPF, XNA.
- I see companies like Apple doing this with HTML(5), Cocoa (Touch) for their iOS platform
- I see companies like Google doing this with HTML(5), Java for their Android platform
The way I see it, the fundamentals that were written up in the “Future of Silverlight” blog post haven’t changed – Silverlight still occupies a great place today and, whilst remaining deliberately vague, I see it growing out very nicely in the future.
Mike Taulty 