This blog post looks at the fallout after last week’s PDC conference where Microsoft were quoted as saying “our strategy on Silverlight has shifted”, and the resulting fallout in the developer community. In this post I will describe why I think Silverlight has a future ahead of it and exactly where that future lies.
Bob Puts His Foot In It!
Last week’s Microsoft Professional Developer Conference (PDC) has caused quite a stir. It was clear from Steve Ballmer’s keynote speech that HTML5 was taking centre stage, with Silverlight not getting a single mention in his opening speech.
The image below shows a word cloud showing the most frequent words in Steve Ballmer’s PDC keynote speech, rendered using Wordle

This is in contrast to previous events such as MIX9 where (just over a year ago) Silverlight 3 took centre stage. This focus on HTML5, which many see as a competing technology to Silverlight was enough to get the community a little worried, however, it was the interview that Bob Muglia gave to ZDNet that really caused a storm.
The key quotes are given below:
“[...] when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, our strategy has shifted.”
“But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform”
The above statements caused quite a stir, with calls for Bob to clarify his statements which seemed to contradict the recent “Future of Silverlight” blog post which contrasted the difference between standardisation (HTML5) and innovation (Silverlight) to show a very positive future for the technology. I think this is the first time I had seen such a direct comparison of HTML5 vs. Silverlight from Microsoft’s Silverlight team, and the arguments they made were quite compelling.

Bob Pulls His Foot Out Again
As a result of Bob’s interview, which was commented upon by virtually everyone in the Silverlight community (Jeremy Likeness, Mike Taulty, and many many more), Bob quickly followed up with a blog post where he stated the following:
“I said, ‘Our Silverlight strategy and focus going forward has shifted.’ This isn’t a negative statement, but rather, it’s a comment on how the industry has changed and how we’re adapting our Silverlight strategy to take advantage of that”
However, I think that the most important point he made came at the very end of his post:
“The purpose of Silverlight has never been to replace HTML, but rather to do the things that HTML (and other technologies) can’t, and to do so in a way that’s easy for developers to use.”
I think it is people’s misunderstanding of the differences between Silverlight and HTML that caused most of this uproar in the first place. It is this point which I would like to concentrate on, and hopefully provide a bit more clarity.
PDC is an Event
Before I focus on the differences between HTML and Silverlight I think it is worth noting that PDC is an event, and just like any other event it needs to be marketed in order to fuel people’s interest and get them through the door. Microsoft embraces a very wide range of technologies, and if the PDC tried to be a true reflection of this diversity it would be very fragmented and hard to market. It is much better that the event focuses on something new and interesting to provide an underlying theme. This year that theme was HTML5.
Interestingly after MIX9 where Silverlight was the main focus and out-of-browser support was announced, there was noticeable unrest amongst the WPF community, they felt short-changed (4 MIX sessions on WPF to Silverlight’s 31) and there was speculation that Silverlight would replace WPF entirely. However, when the knee-jerk reactions were forgotten about and a more sensible analysis of the difference between the two was considered (see Pete Brown’s Future of Client App Development blog post for example), it was clear that WPF does have a future.
The Web Landscape
Back to HTML and Silverlight, if we look at the current landscape of the internet we can crudely characterise web sites and web based applications based on the degree of interactivity that provide:

In the above diagram we see a sliding scale of interactivity and complexity with a few well known sites positioned along this scale (don’t ask me about what units I am using to measure each site!).
With the above sliding scale we can position the popular internet technologies based on their relative strengths and the types of site they are most suited to:

I have not tried to pin each technology to a specific location on the scale because in my opinion the boundaries between each are blurred … a lot. It is possible to use any of the above technologies to create a web site / web application at either end of the spectrum, however, the further away you move from the ‘comfort zone’ of each technology, the harder the job becomes.
We’ll start at the Flash / Silverlight end of the spectrum. Why not capitalise on the fact that these plugin technologies provide a controlled environment for your code to run in, providing great performance and virtually zero browser compatibility issues?
Whilst this point may not have been addressed in great detail for Silverlight, there are certainly numerous strong arguments presented on the internet which describe quite clearly why full-page Flash sites will never fully replace HTML (For a thorough analysis take a look at Emil Stenström’s blog post on Flash vs. Ajax sites). The main reasons cited are:
- Splash screens – Flash / Silverlight sites need to load the entire ‘executable’ before they can render. Contrast this with how quickly the pages from Wikipedia appear.
- Maintenance – Quick fixes are often required for websites, with HTML / JavaScript this can often be left to the support team. For Silverlight / Flash this requires a full rebuild of the application.
(There are a number of other points, including search engine indexing, etc …)
There is not a strong case for replacing simpler web sites with Silverlight. I think my fellow WPF Disciple Justin Angel’s blog, which is powered entirely with Silverlight is unfortunately a good illustration of why Silverlight should not be used to replace HTML for the presentation of largely static content. Sitting here on a train using the pitiful WiFi connection I can see Justin’s stylish loading ‘splash screen’, however, after I minute of waiting I grow tired of staring at his beard and sunglasses and little else!

On the flip-side, when HTML and JavaScript technologies are used to create complex applications, development becomes costly and complex. Cross-browser problems, lack of support for business concepts such as controls and validation, performance issues all start to have a significant impact on the development. To combat this more and more sophisticated solutions are being applied, from the numerous libraries that abstract the differences in browser DOM APIs (jQuery etc…) to Google Web Toolkit, which generates JavaScript code from Java (which provides strong typing and better structuring).
Interestingly in the book Google Closure the Definitive Guide, the preface describes how Google Closure (a JavaScript compiler and mechanism for checking types) was developed to combat the problems the Google Mail development team were experiencing in developing a complex JavaScript application composed of tens of thousands of lines of JavaScript. The take-home message of this is that for complex applications you need more than the JavaScript language alone provides.
Bob’s Comments in Perspective
In the previous section I described how the web landscape can be illustrated as a sliding scale of complexity, with HTML and Silverlight at opposite ends of the spectrum and HTML5 sitting somewhere in-between. With this in mind, Silverlight developers should not fear that HTML5 will replace Silverlight. Whilst it is true that there is some common ground between the two, i.e. a certain interactivity / web-site complexity where the two technologies are equally suited, Silverlight users should feel comfortable that for the more complex problems, Silverlight has a clear advantage.
To repeat Bob’s closing statement of his follow-up blog post:
“The purpose of Silverlight has never been to replace HTML, but rather to do the things that HTML (and other technologies) can’t, and to do so in a way that’s easy for developers to use.”
I think it is the failure of the developer community to realise that there is little direct competition between HTML5 and Silverlight and failure of Microsoft’s marketing to highlight this.
The Web Increases its Reach.
However, there are some important points to note in Bob’s comments and his reference to iOS (i.e. iPhone, iPad etc…). Whilst I do not think HTML5 is a significant threat to Silverlight for web based application development, the introduction of a more diverse range of mobile devices potentially increase the market for HTML.
Most people who use an Android phone or an iPad do not use them as a replacement for their laptop or desktop PC. They use them on the train, in the coffee shop and at home on the sofa as a way to stay online and connected for more of their waking hours. HTML5 is a suitable technology for delivering a interactivity to a diverse range of devices and it looks like the overall market size is increasing.
However, if Microsoft can produce Silverlight plugins for these devices, on the Android phone for example, there is no reason why Silverlight cannot be part of this growing market, delivering more than just interactivity to the mobile platform.
Unfortunately, more recent news, like today’s announcement by the Bing Maps team that seems to indicates they will be dropping their Silverlight based 3D libraries in favour of HTML5 is going to fuel the fire which Bob and Steve Ballmer are currently trying to dowse.
Regards, Colin E.
Tags: HTML5, News, silverlight, WPF


email: ceberhardt@scottlogic.co.uk
on Google+



Hi, just reading through some old posts and I really love this one. Sorry for being so late =0)
Glad you enjoyed it
[...] The Silverlight Firestarter event last week (December 2nd 2010) saw Microsoft’s Scott Guthrie use his keynote speech to announce the launch of Silverlight 5 which will emerge at some point in the first half of 2011. The new features, which my colleague Gergely details in a recent blog post, are geared towards media and business applications, which in my opinion is a good thing. This further re-enforces Silverlight’s positions as a plugin for application development, making it easier to differentiate it from HTML5. [...]
Interesting… Amazing the amount of hysteria that a clarification on the role of silverlight can generate. Remember there is always mono touch if you’d like to reuse C# code used with silverlight on a iPhone/iPad.
I disagree that development in JavaScript necessarily becomes more costly and complex than Silverlight for a complex business application.
“Cross-browser problems, lack of support for business concepts such as controls and validation, performance issue”
Cross-browser problems – Most of the difficulty that you point out with web development comes from supporting non standards compliant technology written by Microsoft (IE6/IE7) – sound familiar? Cross browser issues are not really issues once you move into the range of modern browsers. If I decide to use the Google Chrome Frame plugin then all my IE6/IE7 issues go away and I can write in a platform where it is standards compliant and “provide(s) a controlled environment for your code to run in, providing great performance and virtually zero browser compatibility issues” with the advantage of being code that at a point in the future will run on mobile/desktop. because we all agree that HTML isn’t going to die? by the by Chrome frame plans to remove the need for admin install opening it up to locked IE6/IE7 machines – http://blog.chromium.org/2010/09/google-chrome-frame-stable-and-speedy.html
Lack of support for business concepts such as controls and validation – most of the problems come from existing code – now that there are a lot of frameworks around to help with controls and validation (plus extra browser controls on the way in HTML5) You could argue that if one was going to choose between starting from scratch in Silverlight and starting from scratch in HTML, that there is no difference in the amount of support for separating view/content and having off the shelf controls and validation. I see lack of these features written into the language API as an advantage to choose an external API which provides the features necessary.
performance issues – again, this is mainly a problem with IE6/7/8 and is mainly a problem with badly written code. Badly written Silverlight I’m sure will also have issues. Using an example of a software company – google – not initially using good practices as a reason why no-one can develop in a good way for the web is a bit below the belt.
Importantly it’s easy for a good developer to look at a plethora of existing badly programmed web applications and compare it to a modern technology and therefore primarily greenfield applications.
I think Microsoft would love Silverlight to be in a position to be favoured for web applications and I don’t doubt that they will do everything in their power to do this – being in control of the technology everyone uses is what has given them the considerable market power they have at the moment and now they are losing the fight over the web, they want to cover all angles to try to get back to be top dog. So if Silverlight can succeed I imagine Microsoft will do there best to help, not drop it for a technology that they don’t control.
We’ve all seen how the problem with plugins (like flash) is that if you don’t control the host platform (Apple iPhone..) then you can get serious problems. The only way to combat this is through standardization.
It’s interesting to read the blogs responding from the other angle, e.g. http://www.quirksmode.org/blog/archives/2010/11/microsofts_stra_10.html
Unfortunately its a double edged sword – does Microsoft need better HTML support in their phone to be competitive in order to offer a significant market share of the mobile market that it is worth developing in Silverlight for?
However I don’t think it’s worth worrying about – If a business decides it only needs a desktop application then it can go with Silverlight and I’m sure the plugin will be supported and grow in use for a long time and with the prevalence of IE6/7/8 if its got to look flash it’s the best solution. But the alternative isn’t necessarily a fallback to web development 5 years ago – a business can join the frontier of web development and create code that runs desktop, mobile and server side. They just need to invest in good developers, training and use the new tools and technologies that are forming to support advanced web development (and is the long term cost of that more than getting good developers trained in Silverlight?)
In summary – if you don’t care about mobile and want something fast and flashy now, go silverlight and I’m sure that won’t go away. But don’t argue that web applications by their nature are inferior.
Amen to that
Although I think Flash/Flex has been unfairly dismissed in your post, especially as it is the direct, and vastly more prolific, competitor to Silverlight when creating “flashy” applications.
I think Silverlight’s desktop niche (after all there isn’t a real distinction between web/desktop in users eyes and the WP7 mobile niche is a given) is going to be in the business/enterprise space. Here the amount of developers who are comfortable with the Microsoft/Visual Studio stack (if not with the specific technology/API) far outnumbers skilled, i.e. application level, Flash/Flex or JavaScript developers.
In a time when new target platforms are springing up everywhere (netbooks, mobiles, tablets, etc.) I think it’s a shame that people are investing their time in learning the Silverlight/WPF APIs and techniques (which are different and do require some getting used to) when they could be investing the same time in either JavaScript or Flash/Flex APIs and techniques, both of which are far more ubiquitous platforms.
Unfortunately I feel the reason for developers not investing time in Flash/Flex/JavaScript is that they’ve previously used (or currently use) them without ever investing the same level of learning. The inevitable result being that they end up either re-inventing the wheel or with a real mess of code, assume that’s the best you can do and give up.
To anyone reading this looking for a good starting point in JavaScript, let me also as Colin did point you to Closure The Definitive Guide, but let me put a different spin on it -
Google has now open-sourced their API, tools and documented the techniques they used to build world class applications such as GMail and Docs (interestingly listed above as more “application-like” than any Silverlight app). Instead of moaning about JavaScript why not take the tools that the major player in the industry is using and embrace them as part of your development, after all Silverlight wouldn’t be anywhere near as popular if you had to use notepad!
Chris
Keith, do not believe that. All the issues that Colin mentioned are there and are going to be there even with modern standards supporting browsers. Different platforms, different browser engines, different approaches, different bugs, etc. You will always have to test on all the platforms, all the browsers a and you will have to adapt. Silverlight helps to avoid this. And Javascript as a dynamically typed language is meant for scripting as its name suggests. It is simply not suitable for complex application development. The Google mail and GWT are nice practical confirmations of that.
On the other hand, for web pages and simple applications HTML5/Javascript are just fine. But that is not what the fear is about. The fear is that Microsoft is going to push HTML5 at the expense of Silverlight even for complex applications, slow down its development, stop adding new platform support etc.
I’ve been a professional developer for 15 years in a variety of languages with a heavy dose of C++ at the front end of my career. In the past several years I’ve completed two web application projects, one using mostly javascript and one using Silverlight (C#).
Let me say this–for full blown professional level applications, javascript may be the worst language ever created. It’s a complete mess. The idea that anyone would want to standardize development on this joke of a language is just baffling to me. Javascript is fine for basic scripting needs. But for a full application? You better like being a hacker, because at least half of your time is going to be used up figuring out how to hack around things that are broken or don’t work properly in browser X. Not to mention the absolutely lack of real development tools you are forced to work with. Or that you have to depend almost exclusively on 3rd party API’s that attempt to hide all of the intrinsic flaws of javascript within their huge libraries of functions.
I think I’d rather stick a hot poker in my eye than ever try to write a large internet app in javascript again. Not that I don’t still use it–I do. For certain smaller tasks, javascript is fine. But for writing object-oriented applications? It’s just a horrible, horrible langauge, and I shudder at the thought that it is somehow the “future”. It’s like if someone came forward through time from 1983 and told everyone that from now on, everything was going to run in compiled basic. Except that compiled basic was actually superior to javascript for application building since it could actually detect problems in your code before run-time.
All this “MS is dropping Silverlight” hysterical nonsense is kind of interesting to watch: it shows how SCARED they competitors are as nothing even comes close to Silverlight and its toolchain, Expression Blend and Visual Studio 2010, plus the leverage developers get from first class PC-Mac-Phone cross platform support. HTML 2022 is certainly not a threat to Silverlight today…
Amen to that
Colin, better double check that Bing Maps page you linked to. They’re now claiming they’re not dropping anything related to Silverlight.
Even if they had, though… For a major consumer site like Bing Maps, the need to use plugins for specific features is undesirable for obvious reasons. It [almost always] decreases the number of people who can use those features, and for the people who can, it [sometimes] adds an extra step for them. If it’s practical to implement functionality without a plugin, that’s better. Plugins are for those cases where you just can’t do it any other way, whether it’s due to technical limitations, limited resources, or whatever. I think this is reasonable and typical thinking ***for a major consumer site***. It would be stupid for people to fuel fires based on such decisions, but I’m sure it would happen anyway. I’m not sure I’ve ever seen such desperate trolling as I have in the comments on Muglia’s blog post.
Hi Tom,
Thanks for the update about the Bing Maps page, I just checked it again and they have posted an update, just as Bob Muglia did.
I picked up on the Bing Maps article because of the torrent of tweets stating that Bing had dropped Silverlight in favour of HTML5. I read the article, and to my mind it didn’t read like that, which is why I stated that the article “seems to indicates they will be dropping their Silverlight based 3D libraries in favour of HTML5″
You are right, there is a lot of trolling going on, however, Microsoft have not made their position clear. People need more help in understanding the web landscape, and that is what I tried to do with this blog post.
I am not just another troll – honest
Regards,
Colin E.
Oh I’m not saying you were trolling with this at all. It made sense for you to point it out, they just posted an update is all. Actually you put together a pretty extensive and well thought out post that added some new or at least better explained material to this discussion. I like your look at interactivity and complexity of different sites and how that relates to different technologies. The point about comfort zones for each technology is really key, I think. How much are you willing to move away from that comfort zone to get an attractive benefit like no plugin requirement? Can there be a solid enough trick to cheat the comfort zone (like GWT or Script#)? How will your choice affect you over time? Lots to consider.
Does HTML5 mean the end is in sight for Silverlight? | Colin Eberhardt’s Adventures in WPF…
Thank you for submitting this cool story – Trackback from DotNetShoutout…