Choosing Client Technology Today for Tomorrow

(by Brian Noyes)


Choosing the "right" client technology today is one of the hottest and contested questions we help IDesign customers address. I hope in this little missive to clarify our current thinking, in the face of the plethora of options, past decisions made, new technologies, misconceptions, and what we see our customers opting for. 

Basically, it comes down to this question: should we use Silverlight or WPF, or should we abandon them and go with an HTML solution? It turns out this question is actually multiple questions compounded. You really need some additional context of the kinds of client applications you are building, who your target audience is, what platforms you think you need to run on today and in the future, and where your team's skills are. 

Really there are three primary paths that you should be choosing from today: build Windows clients with WPF or Silverlight and not worry about multi-platform, build multiple client applications - one for each target platform using the appropriate native technology - with common backing services, or build HTML applications for maximum reach. Each has its benefits and pitfalls and requires you to make tradeoffs. 

HTML5/JS applications may seem the most attractive because of the promise of multi-platform support. But you also have to take into account what you are giving up in terms of productivity and capabilities. There are still many things that business apps need today that will just not be possible or will be extremely difficult to achieve in the browser with an HTML5/JS application. You also need to fight the misperception that an HTML5/JS Metro application is any more multi-platform than a XAML based one - it is not. You just happen to be building a Windows application with those languages, but the implementation and even coding patterns you employ will be very different for a native Windows Metro application than they would be for a browser application. 

If you choose Silverlight because it is "multi-platform" (which really only means Windows and Mac), you are probably on a dead end path and probably should switch to HTML5/JS for the long term. It is pretty clear that Microsoft has no intentions (whether there is an SL6 or not) of continuing to invest in Silverlight as a cross-platform technology, if at all. The exception is that one definition of cross platform is Desktop/Browser/Phone/Xbox, which does appear to be a safe track for Silverlight in the near future. 

If you choose Silverlight or WPF because they are the best, most productive platforms for building rich business apps for the Windows platform, then you are on the right track. 

Choosing between Silverlight and WPF can be a little tougher. Silverlight is your best choice if you think you want to port your application to run in Windows 8 as a Metro style application some day. Silverlight and Metro require you to have the same kind of architecture, executing environment restrictions, adopt the same asynchronous patterns, and more. However, if your application is a desktop application now and you envision it staying that way for a long time to come and not becoming a Metro app, then WPF will still give you the greatest power, flexibility, and productivity for building rich desktop client applications for the Windows platform. 

What we have in SL5 might be it for the long term, as there may be no subsequent releases. But that doesn't necessarily mean you have to jump ship right away, especially for desktop applications. Running Silverlight applications as browser applications does have some risk because even though Microsoft has announced support for SL5 for 10 years, they have not said they will make sure it works with the next 10 years worth of browser versions and potential new browsers. Your users will probably want to keep their browsers moving forward, but a Silverlight browser application might keep you tied down at some point in the future. Silverlight desktop applications (Out of Browser mode) are just as safe as all the Windows Forms applications are that have been running comfortable even though there have not been any substantial updates for Windows Forms in 6 years. 

At the end, it all boils down to who your target audience is. 

If your target audience is business employees on company computers, then Silverlight is a good path in the near term, with a possible migration to WinRT/Metro in the future for some of the functionality. If you have a good understanding of what a Metro application is and what the constraints of Metro are and you can't envision your application running as a Metro application, then stick to WPF. 

If your target audience is consumers, Silverlight is a terrible path to be on for the long term, unless it is part of a multi-native-client strategy where you will have native clients for Windows/iOS/Android/Mac backed by a common set of services. If so, Silverlight as a bridge technology to WinRT/Metro for the Windows clients is a good path to be on. Otherwise, HTML5/JS is the only safe path for a consumer facing app if you are really trying to build one and only one client app. 

If your target audience are business employees, but highly mobile ones, the choices are roughly the same as consumer these days, and becoming more so all the time. The days of the dedicated company desktop computer that is there to perform one job function are quickly fading into the past. 

The above makes the choice of XAML technologies a tough one unless you are willing to commit to the multi-native-client strategy, which is the best choice from a user experience perspective, but certainly one that takes some more resources to pull off. Going HTML 5 means a significant productivity hit, especially depending on the skills of your team, and significantly different application architecture, technology choices, learning curve, etc. Eventually, I think many companies will choose the HTML 5 path. But as an architect, I think the right choice in most cases is a good service-based architecture with multiple native clients to cover the Windows-Mac-iOS-Android space.