More on Microsoft’s difficult choices: WPF, Silverlight, HTML 5

Earlier today I posted a story speculating about the future direction of Microsoft’s development platform, which has proved controversial and to some extent has been misunderstood. Although it is speculative, the issues are important since developers want to target platforms with a strong future. Here’s another take on why Microsoft, whichever way it decides to go, faces some difficult choices.

First, let me be clear: I don’t see Microsoft abandoning Windows Presentation Foundation let alone Silverlight. Microsoft has an good track record when it comes to continuing support for its technologies, better than competing platforms. Visual Basic 6 applications mostly still run today on Windows 7, perhaps with a few issues caused by User Account Control for which there are workarounds. Whatever you target, there is an excellent chance Microsoft will continue to support it long into the future. The main exception I can think of is Windows Mobile, which is incompatible with the new Windows Phone 7 series, but given the challenges Microsoft faces in mobile you can understand the decision.

Nor is there any chance of Microsoft reviving old frameworks. There will not be a return to Windows Forms. WPF is a better GUI framework in every way, other than performance on older systems – though note that Windows Forms applications still run fine today, and I imagine will run fine on Windows 8 and probably 9 as well.

The real question is not about support, but future investment. Microsoft has finite resources. It is in overdrive right now on Internet Explorer, on Silverlight, on Windows Phone 7, and on Azure, for example. There will be other products and technologies that receive less attention, because someone has decided they are not strategic.

It also seems to me that Microsoft’s server and cloud story is less conflicted. From the developer’s perspective it is thoroughly .NET based, and you can be confident that technologies like C#, IIS, ASP.NET, SQL Server, Exchange and SharePoint will be around for the foreseeable future.

With that out of the way, a few further comments.

Windows Presentation Foundation

The history of WPF goes back to the early days of Windows Vista, then called Longhorn. WPF was one of the the “three pillars”, Avalon, where the others were Indigo (WCF) and WinFS. Avalon was the future of the Windows GUI API, based on .NET code and XAML layout.

If Longhorn has proceeded as planned, WPF would be the loose equivalent of Cocoa on Apple’s OS X, the standard way to code Windows GUI applications. Unfortunately, in 2004, Microsoft discovered that Longhorn was heading for disaster. The project was reset, delaying release and resulting in Vista being both late and rushed. The reset project included Avalon as a supported framework, but made it incidental to the workings of Windows itself. The Windows team, in other words, lost faith in Avalon and reverted to native code with a dash of DirectX.

Windows 7 is more of the same. WPF is there but it is not at the heart of the OS. Developers are encouraged to use it for their own apps, but the Windows team is focused on native code.

When Visual Studio 2010 was released, with a shell built in WPF, Microsoft made some noise about how it showed its commitment to the framework. It was also noted that the Visual Studio team had worked with the WPF team to fix some issues. However, there is little sign of WPF changing its role as a layer in Windows primarily to support custom applications, rather than being used for the shell of Windows itself.

The question now: how much should Microsoft invest in future WPF development? It is not essential for Windows itself. Nor it is compelling for developers wanting to take advantage of the cloud model and support diverse clients. Frankly it does not look strategic unless it becomes the Windows shell API; and you could understand Microsoft having a “once bitten twice shy” attitude to that possibility.

I find it plausible that Microsoft would throttle back on WPF development.


Silverlight by contrast is strategic. Silverlight is a framework that runs in the browser, out of browser, and on Windows Phone 7. It is lightweight and cloud-oriented, and it runs .NET code, ticking lots of boxes for developers moving on from Windows desktop applications. It is also designer-friendly, with rich graphics and multimedia support. There are still a few gaps – printing is crude, for example – but it makes more sense for Microsoft to invest in Silverlight than WPF. It is significant that the new LightSwitch tool for rapid development of database apps targets Silverlight, not WPF, and not ASP.NET (except on the server). Silverlight is also the application platform for Windows Phone 7.

Then again, Silverlight is WPF. It was originally WPF/Everywhere, and uses the same XAML language for layout.

I will be surprised if Microsoft back-pedals on Silverlight. Nevertheless, I can also understand this being a matter of debate. Despite Microsoft’s efforts to distinguish them, there is considerable overlap between what Silverlight does, and what HTML 5 in IE9 does, especially when in the browser. There is also the Apple problem: HTML applications will run on iPhone and iPad, but Silverlight will not. What if Microsoft focused on the new IE engine instead of Silverlight, supporting it properly in Visual Studio, and providing ways for developers to create out-of-browser apps that run with full trust and have access to local system APIs? This would be along the same lines as the Palm WebOS and Google’s Chrome OS.

Put another way, does it make sense for Microsoft to invest equally in HTML 5 and Silverlight, when possibly IE 9 could be the basis of a unifying technology, a subset of which would work on any modern browser on any client?

It seems to me that Microsoft will have to invest in tooling for HTML 5 clients in some forthcoming edition of Visual Studio, and that this will be a selling point for its cloud platform, while possibly undermining the role of Silverlight.

There is also a continuing case for Silverlight, both because of the inherent advantages of a plug-in – consistency of client platform as well as features that HTML 5 lacks – and because it supports .NET. The .NET languages (Mono aside) tie developers to Visual Studio and to Microsoft’s platform. Visual Studio combined with .NET is a formidable tool for both client and server and a key advantage for the platform.

Watch this space.

8 thoughts on “More on Microsoft’s difficult choices: WPF, Silverlight, HTML 5”

  1. Great post, and although I felt this morning that Silverlight was looking like it was on borrowed time given the poor uptake and the inroads Apple have made (first with the iPhone, but suddenly and dramatically with the iPad) this afternoon’s AppStore licencing changes announcement from Apple changes things somewhat. Suddenly that increasingly important Apple platform that had been cut off and which may have necessitated using HTML 5 looks potentially supportable with Silverlight through some sort of cross-compilation or enhancements to MonoTouch.

    What developers don’t want (we’ve been round this loop one too many times already) is to have to rewrite the same application (or UX) multiple times for all the myriad platforms out there. The minumum needed for typically Microsoft-centric shops was starting to look like HTML 5 for the iPads and bleeding edge browser users, and if you were prepared to pay twice in time and money maybe a second development for Silverlight to reach those 60% (allegedly) who have the plug-in installed.

    Silverlight has one big strength, particularly for the UK, in that it enables rich UX EVEN ON IE6. IE6 isn’t going away any time soon thanks to government cutbacks on IT spend and recent announcements that government IT depts will have to stay with IE6 as a cost-saving exercise. However Silverlight has a steep learning curve (despite what Microsoft may tell you) especially for web developers unfamiliar with MVVM, asynchronous programming, LINQ and various associated technologies like WCF RIA Services, Entity Framework, MEF and Unity (or other IoCs). I’ve even heard some within MS say that Silverlight is now perceived as possibly holding developers back from developing for Windows Phone 7 (which Microsoft are desperate to get applications for to ensure a strong launch), where the original assumption had been that use of Silverlight would actively encourage more to jump on board.

    However you look at it (from the point of view of businesses wanting application written in it, or developers eager and knowledgeable enough to learn it and use it) Silverlight is a niche product, despite the public line about it being Microsoft’s “premier UI”.

    This morning it seemed like the future of the technology was tied entirely to the success of Windows Phone 7 (which certainly isn’t guaranteed) but the announcement this afternoon from Apple may well give Silverlight a further reprieve, which for those of us who work with the technology and like it, is good news. Some of us don’t want to go back to JavaScript, we really don’t. But against that HTML 5 is pretty much guaranteed to stick around, especially because MS will overly promote it as part of their usual “embrace and extend” strategy. On that basis HTML 5 still looks a “safer” bet, at least for cross-platform web apps, than Silverlight for most, even if it isn’t really fully-formed yet. Interesting times!

  2. @Ian Couldn’t agree more Silverlight’s learning curve. It doesn’t help that a lot of Silverlight devs come from the WPF world, who talk about MVVM etc, rather than from the HTML world, who’d focus on HTML and Javascript. The use of datatemplates for styling rather than CSS is another pain point for those coming from the HTML world. If MS wants to attract HTML devs, they’d need to provide a CSS interpreter that maps to VisualStateManagers and Templates.

  3. @chui I think you must mean instead of . Silverlight/WPF styles are more similar to CSS than datatemplates.

    On that note, I wouldn’t want SL/WPF styles constrained by css anyway. Styles are far superior, mostly because you can actually inherit them. For example, in SL wpf you could create :

    a) A BaseFontColorStyle
    b) A BaseFontStyle that inherits BaseFontColorStyle
    c) A BaseTextStyle that inherits BaseFontStyle
    d) A BaseTextBlockStyle that inherits BaseTextStyle
    e) A BaseButtonStyle that inherits ……

    And that is before you even start on ControlTemplates and DataTemplates. All of which can inherit use the styles, and then inherit and compose from each other. This makes skinning an application very easy and consistent, and fast to build once you get the framework in place.

    And don’t get me started on how lame css/html is for doing layout compared to xaml. It doesn’t even compare. Xaml is logical, structured, heirarchical, consistent. Css/html is horrible, tangled, a big hack, unreliable..

    CSS and html doesn’t haven anything like templates. And css doesn’t do inheritance, certainly not when I last tried.

  4. Tim,

    Abandonment has a variety of definitions in this space, but with WPF its a case of park it on the shoulder of the road, leave the keys in it and walk away. The team for WPF have been reduced to a small crew whilst others focus on Silverlight or the vNext shiny toy thats coming up off the assembly line. Furthermore Scott Gu’s org has been re-org’d to now focus on more of a functional based development methodology and less on a product specific as it has in the past – they’ve done away with the concept of Product Unit Managers etc..

    This means that in a sense there is caretaker mode and at the same time focused effort around big ticket software that needs to be produced, so when you have a situation like WPF waiting ever so patiently in the wind it kind of ends up being a lower priority over time and maybe just maybe it might get a look in when the moons are right or the will of the executive overlords decide to show it some minor mercy here and there hehehe.

    Combine that with a key GM leaving the WPF space and the company recently it just kind of smells bad overall. As a Product Manager for WPF and Silverlight i used to sit in meetings with these guys and they would beg us for marketing budget to push it further and wider but we simply ignored the request and instead focused our efforts on Silverlight given that’s what Scott Gu’s marching orders were..

    The reality is this. WPF has way more ubiquity than Silverlight today – approx 80% of Windows enabled PC’s have .NET 3.5+ and Silverlight depending on which stat you want to buy into has at best prob under 50% realistically and it’s not looking to increase given its really lost a lot of its marketing momentum due to infighting, reorgs and all the usual churn that goes with a day in the life of a Microsoftie..

    Getting rid of WPF officially will never happen given it’s got deep touch with some top ISV’s (ie while it doesn’t have a breadth story thats hot, it does have a depth story which goes into large enterprises deeply – ie Autodesk 3DSMAX 2010 etc are all on WPF). So declaring it dead unofficially is probably the closest you’ll get to an absolute truth here but its how Microsoft will cast it aside is where the real darks secret exists :/

    Anyway i wouldn’t of spoken out about this if i didn’t feel like it was a situation that was getting worse and it’s mainly due to top-down political infighting and less on the greater good of .NET? to which i just go “seriously, we should just knock this shit off” 🙂

  5. @Scott,

    You are a s***-stirrer but you are absolutely right. There’s so much focus on shiny objects that it is very discouraging to MS developers. There is not much chance that whatever platforms you build on will continued to be nurtured.

    MS needs to extend the concept of backward compatibility with old software to forwards compatibility with old programmers, or risk having their ground worn away by the relentless march of alternate platforms that continue to improve incrementally. Just look at the data access technology. They are so immature despite MS being around for ages. They keep throwing good stuff away instead of building on it.


  6. @Chui,@Scott,

    I think chasing shiny objects happens at any forward looking company, our team worked on 4 different technologies in the last 1 year, (webform), flex 3/4, Objective C and now HTML5. We also tried writing an application in SilverLight, and frankly there is a long learning curve to make any SL app reasonably professional.

    Also for Win 7 phone, dev’s don’t need to know the full SL framework as Win 7 Phone is going to use very specific templates for view and navigation, most people won’t be exploring any more controls than they need to, just like all those iOS developers. Apple’s own Videos/Movies apps internally use webkit control’s for most of the stuff.

  7. If you need a good Silverlight application hire one great wpf developer and one good backend developer and take it from there. Don’t hire anyone else until the prototype runs on required platforms and then hire more. Then keep your fingers crossed that the goal posts don’t shift after two months of release and your money goes to waste. Not unlike developing any other app…

Comments are closed.