Silverlight: next decade's IE 6 problem

In the "should I use HTML or Silverlight" debate, one thing that's overlooked is the impact that future browser releases will have on whether your application will still work in 5 or 10 years time. Let me play out a scenario I've been thinking about.

First, an important observation:

When new versions of Silverlight are released, Microsoft (and Novell) have to release new plugins for each of the major browsers.

Well, that's kind of obvious. Perhaps less obvious:

When Chrome, IE or Firefox re-write their plugin systems, Microsoft (or Novell) will have to release new plugins for those old Silverlight releases.

Right now the support matrix isn't too bad. Silverlight 1.0 applications won't work in Chrome, but no one ever used Silverlight 1.0, so that's OK. But how long will they be able to keep this up? If IE 10 includes a new plugin engine, I'd expect a new Silverlight plugin for Silverlight 4.0, but what about 2.0? At their current rate of release, by the time Silverlight 6 comes out, will Microsoft even be able to afford to test 6 different Silverlight releases across 3-4 different browsers?

This means that if you have a production application running Silverlight 2.0 right now, you're relying on Microsoft releasing Silverlight 2.0 plugins for every new browser, from now until your application is retired, in order for the application to work.

Of course, if they don't, that's OK. You can always upgrade your application to the latest version of Silverlight, which probably does have a plugin. Right?

Not so fast. What's cheaper? Getting developers to upgrade old technologies to new ones, or just telling users not to use that latest IE/Firefox/Chrome release? Which option will most corporate enterprise IT departments pick?

Sound familiar? It's the same problem we have with IE 6 right now. We built so many applications that only work in IE 6 that enterprises decide it's cheaper to tell users not to upgrade, to the point that IE 6 still has incredible market share.

This leads me to the conclusion:

Today's corporate Silverlight applications will produce the future equivalent of the IE 6 problem.

Being serious, I think this should matter to corporate application developers considering Silverlight when HTML would do. Since enterprises rarely do a good job of keeping their application technology stacks up to date, to have confidence we need some kind of guarantee from Microsoft that Silverlight 2.0, 3.0, 4.0 applications will be supported not just by current browsers, but by the popular browsers in five years time. I've not heard of any such guarantee so far, and I have doubts that they can.

On the HTML front, it's likely that if you had instead chosen to use standard HTML and CSS, your site will continue to work even as new browsers are released, since browsers are trending towards better standards support rather than getting worse. No serious browser vendor is going to release a browser in the next 10 years that doesn't support XHTML 1.0 or HTML 4.01. And besides, web standards only seem to change every 300 years on average.

As far as I can see, come 2015, your "Valid HTML" site stands a better chance of being used by 2015 technology than your Silverlight 4.0 application.

Edit: Nick Kramer from Microsoft has posted some background about how Silverlight compatibility works and how the team plans to support it going forward, which puts me at rest somewhat.

A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

09 Sep 2010

While I agree to some extent, I think we are to blame if this scenario ever pans out. We ask for the latest and greatest. We want the new shiny stuff to build on, and we like the quick turnaround for technology stacks because of the development advantages they offer, yet we do not question the commercial ramifications because that would be going beyond our sphere of consideration. How many devs cannot wait for v.Next because it offers the potential to do feature 'Y' which could not be done before in a supported way. I think we should bear the brunt of the outcome if what you say is true, because we asked for it.

09 Sep 2010

@Glav, I agree. We have to choose carefully.

If we were building public websites it would be different, since public websites do tend to get changed and updated frequently, and companies will spend money to deal with the compatibility issues. But in the internal enterprise LOB world, they like to cut corners - which means users get stuck with IE 6 forever and we all suffer :)

As you say, that kind of long term impact isn't usually something we pay much attention to as developers.

09 Sep 2010

Well M$ has Windows Phone 7 now so the browser plug in can die now! :-)

09 Sep 2010


Jeffrey, this is not slashdot, and we're not 13.

Paul - sorry to disappoint you but no one will use Silverlight for public-facing webpages, and for intranet apps the solution is very simple.

Stick to IE6 for your SOE, and then everything will just work :)

09 Sep 2010

You certainly make a good point. Though, as for my company, most of the Silverlight work we have been doing is more along the lines of cross-platform desktop applications via SL's OOB support. In those cases the browser doesn't matter except as a mechanism for deployment. Think of it as Click Once vNext. Fortunately, should the need arise, you can also install any SL4 app without the need of the browser via SLLauncher on Windows or creating the app package for Mac manually.

Though, devs building "web sites" with Silverlight is certainly a problem. It turns out to be very hard for developers to use the right tool for the job...

09 Sep 2010

I'm not sure if this post is leaning towards the whole html 5 push by so many people around the world but html 5 and or new technology falls under this same paradigm. html 5 won't be supported by TONS of people for a very long time because they will have to upgrade their browsers, which as you've put won't happens for a very long time. At least Silverlight does currently work in all browsers, so it's pretty safe. Besides i don't think many Silverlight applications will need to withstand the test of time for 5-10 years from now. Companies made the mistake by investing so much money on web applications that only worked with IE 6.... I'm pretty sure they've learned their lesson now. I don't think that corporate companies are going to invest money into an application that will need to withstand no upgrades for 5-10 years without some serious though.

09 Sep 2010

Correct me if I'm wrong but isn't Silverlight backwards compatible, eg. Silverlight 4.0 runtime will run Silverlight 2.0 apps just fine? So MS only needs to test the latest version of the Silverlight plugin on the latest browsers. Obviously the enterprises would need to update the SL plugin to the latest version, but isn't that automatic (included in Windows Updates)?

Also why doesn't Flash have this problem. It's plugin system works the same way as Silverlights, has regular updates (upto version 10 now), but has been around for a lot longer. So why haven't we seen enterprises stuck with older browsers because of Flash? Or is Flash just never, ever used in the enterprise?

09 Sep 2010

I'm not sure I agree.

Silverlight is backwardly compatible. Your application built against version N continues to run against version N+1.

This is somewhat reinforced if you take a look at 85% of the users with Silverlight are on Silverlight 4, not Silverlight 3, 2 or 1. Not all those apps they are running were built for Silverlight 4.

So, if a browser manufacturer were to break backwards compatibility with their plug-ins, it would mean a new version of the latest version of Silverlight for that browser. It would not mean an update to every version of Silverlight ever shipped for that browser.

So, whilst it's a nice headline it's not really any different to saying "Microsoft needs to make next version of Windows backwardly compatible with current version" which they've been doing for ~30 years.

By the way - your title also needs an apostrophe in the word "decade's".


09 Sep 2010

Tried adding a comment from my iPad this morning but the comment system is totally whacked when using the iPad. HTML is great! :)

But I agree with the more recent commenters that this doesn't seem like an issue if Microsoft maintains compatibility with SL code developed for older versions of the SL plugin. So, if SL5 supports SL4/3/2, then there really isn't a big issue.

Additionally, I'd be surprised if enterprises are updating browsers at a more rapid pace than the plug-ins.

Right now, the HTML5/CSS3 space is a mess. The problem is being created today outside of the plugin environment when devs rely on non-standardized HTML5/CSS3 features.

I'm not worried about this at all, and building big Enterprise apps using a plugin and having a version plug-in issue just isn't a concern, and I don't think it should be for others. Deciding on whether a plug-in is correct and needed and whether it should be Flash/SL, etc. is a much bigger decision.

09 Sep 2010

The same goes for HTML. We can't expect corporate Html applications built today on standards to work perfectly in browsers 5-10 years from now. This is not a new problem and Html doesn't fix it.

Neil Weber
Neil Weber
09 Sep 2010

Ryan, you missed Paul's point. The problem exists for HTML too which is why corporations have standardized and stuck with IE6 despite IE7 and IE8 being better browsers. Paul is saying that corporations building apps on, say SL 4, will avoid upgrading to SL 6+.

I completely agree with the post. To alleviate the problem new technologies should not be adopted until they stabilize. Looking at the massive changes between SL 3.0 and SL 4.0, I don't think SL is stable yet.

As Paul Glavich says, the fault is with us devs. I am bored with the technology stack my employer is using and am eager to move on to something new.

09 Sep 2010

Hi Paul,

Its an interesting thought. Although compatability problems aren't new, we actually deal with them in a large number of areas. For example Office versions, Exchange versions, SharePoint integration. They all have this class of problem. The browser market just accelerates it in some respects.

That said - Flash has the same problem so I wonder how they solve it? With a well designed platform (and I'd put both Flash and Silverlight in this category) you should be able to isolate the browser integration points from the core of either stacks.

I'm actually more concerned about the usability implications of random plug-in components in applications. I'd go for a HTML solution over Silverlight anyday if I could, and only use Silverlight/Flash for very specific problems where rich media/visualisation is required - or maybe local hardware integration.

11 Sep 2010

I think you are factually wrong, SL4 runtime can execute SL3, SL2 and maybe even SL1 apps. Try this link which is a SL2 app and it's running just fine in Chrome. Further, the same stands true with Flash, the latest runtime can play apps made with older versions, in fact with Flash the compatibility goes back over a decade. So I think your argument is moot, I would even say using SL/Flash you are better isolated from browser changes than otherwise. And with over 500 million installs, I doubt changing plugin-engines will be an issue for SL unless the browser itself wishes irrelevance.

12 Sep 2010

Moonlight somewhat rectifies the compatibility problem, by virtue of being open source. So even if Microsoft is overstrained again to support their own technologies, there will be a baseline fallback for most browsers/plattforms.

But the article is right on the IT departement tardiness. Silverlight might very well become the new ActiveX or IE6. But I suppose, Sharepoint is a worse progress lock-in midterm.

15 Sep 2010

The reason corporations stuck with IE 6 for so long was because all of its quirks made upgrading to the new "player" (IE 7) break everything. This has not been the case with Silverlight.

The current Silverlight 4 runtime still plays Silverlight 3, 2, and 1 code just fine. It has its own built in "quirks" mode to handle the targeted version of Silverlight for the app.

As to the "huge" changes between 3 and 4, you don't need to use them. You can continue to code for Silverlight 3 even if the client machines have Silverlight 4+ installed. When you are ready, you can migrate your dev environment to Silverlight 4, at which point you have to deal with the differences. Not before.

This is more akin to Flash Player than IE6. Yes, the latest version 10 may have some issues playing flash files from a very early version of flash, but for the most part it continues to be able to run older flash files just fine. I do not see corporations saying "we can't upgrade past Flash 9.0 - it breaks our apps!"

16 Sep 2010

While I agree with some of your points, I don't think rewriting plugin is that big of a deal. Here's why I think that :

To me Plugin is just a requirement that satisfies a particular Interface that the BROWSER is expecting. Plugin just takes the request and hands it over to FRAMEWORK no ?.

Plugin updates in corporate environment is just a deployment concern. Just like they update Windows, they need to upgrade runtimes (Assuming it's not a breaking change).

30 Sep 2010

I concur with other comments. This post hasn't been thought through very carefully, and the analogy is illogical.

Silverlight is backwards compatible, therefore sys admins of the future can allow new versions of Silverlight to be installed without fear of breaking old applications.

Ironically, this behaviour is an argument in favor of using plugins vs web apps, in that we aren't coupling the user/organisation to a particular browser / version.

I'm not saying one way or another that you should use plugins but the argument presented is certainly no argument against plugins.