I’ve been hearing a lot of people talking about WPF lately as it if was a poor elderly relative that is terminally ill. “Yeah, poor Fred, he always showed so much promise, but never really amounted to anything. And now he is on his way out…”

I think this perspective on WPF is rubbish, especially for the next couple years at least. Images of Monty Python’s Bring Out Your Dead scene pop to mind, except WPF is vibrant and ready for a marathon, not laying in a cart.

Part of the problem is that as developers we tend to jump on the newest shiniest toy on the playground and forget there are others that are just if not more capable.

The main reason for people talking this way is Silverlight 4. First let me start by saying I love Silverlight 4. The improvements made in this release are fantastic, and do significantly close the gap in capabilities between WPF and Silverlight. And for an awful lot of business and consumer applications out there, Silverlight 4 is now good enough to build those apps using Silverlight instead of WPF. So I am not in any way trying to bash Silverlight, just point out that it is not the only shiny toy on the playground.

The gap in capabilities is still there in substantial ways for certain scenarios that you can’t easily write off by just saying you will build all your business desktop applications in Silverlight now. At some point, maybe a couple more releases of Silverlight away, there will be parity. In fact, by that point, I hope and think the technologies will merge and for a lot of what you do you will just be using the same set of libraries from the framework, and will choose from a range of deployment modes for your application and its host. If that is the case, it doesn’t matter what you call it, it doesn’t make WPF any less relevant today. We already have somewhere between 60-80% code equivalence in WPF and Silverlight 4 depending on whether you focus on the core UI and supporting code or the hosting code.

The main feature that people point to in SL4 that they try to say “See, we don’t need to bother with WPF now” is Out-Of-Browser (OOB) elevated trust. The first important point here is that it is “Elevated” not “Full”. You have the ability to do a lot of things you couldn’t do before based on that elevated trust, but there are still a lot of things you could be blocked from doing that would be no problem in a WPF application. Additionally, for almost all the new things in Silverlight 4, you can look at the corresponding capability in WPF and realize that Silveright is still the “challenged” sibling. Even though these new features cover the 80% for most apps, that remaining 20% might be just the thing you need, and not having it could either cost you a lot of time and money trying to compensate, or penalize your users because of the lack of capability.

Let me run through some of the key differences that make me hesitate to jump too quickly to Silverlight 4 when choosing a client application technology.

File access:

WPF – Unlimited

Silverlight – User profile special folders (My Documents, My Pictures, My Videos, etc.)

Printing:

WPF – Many options, access to Print Dialog, control print queues, etc

Silverlight – Print a UI element programmatically

Documents and editing:

WPF – Flow and fixed document, RichTextBox editing and integration with flow document

Silverlight – RichTextArea control with most functionality of the WPF RichTextBox

Commands:

WPF – Support for raising commands on buttons, hyperlinks, menu items; input bindings tied to commands for keyboard shortcuts; routed commands implementation in the box

Silverlight – Support for raising commands on buttons, hyperlinks, context menu items, no input bindings, no routed commands

Communications:

WPF – Full range of WCF capabilities, able to consume and host services of any kind, full range of security options and other WS-* protocols, REST, low level communications of many kinds

Silverlight – Limited subset of WCF client capabilities, no ability to expose a service from the client, unsecured TCP or HTTP protocols, duplex less capable than WPF clients (polling HTTP or unsecured TCP only), some socket level capabilities, have to take cross domain considerations into mind in most deployment scenarios.

Clipboard:

WPF – Any kind of serializable objects

Silverlight – Text only

Drag Drop:

WPF – Any kind of object

Silverlight – Files only

External devices:

WPF: Anything with a driver, COM, Win32, or communications protocol

Silverlight: Webcam, camera, microphone, and devices with a COM API or compatible communication protocol

Input:

WPF – Keyboard, mouse, pen, touch no real limitations

Silverlight – Must be OOB elevated trust full screen to have full keyboard access

The bottom line is that if your client application is mainly a front end for back end data – Silverlight 4 is perfect and sufficient. But if your client application needs deeper integration with the client machine and other things that reside client side, it may be possible to get it done with SL4 elevated trust OOB, but it will likely be more challenging and you may hit brick walls that kill your productivity or functionality. You really need to do a good up front requirements analysis and if you have any significant interaction with client machine resources, WPF is still going to make your life easier.

That being said, at the current time, WPF is the “Challenged” sibling in terms of a couple of newer technologies. The WCF RIA Services capabilities for generating client side code and having the DomainDataSource is very attractive for a broad range of business application use cases. That will be coming in a future release for WPF, but in the meantime, Silverlight has the leg up there. Additionally, MEF added some convenience classes in Silverlight 4 that didn’t make it back into the main .NET Framework that make certain composition scenarios a little easier and cleaner to code. But that is less of a leg up than the RIA Services part.

As developers and architects, we need to make good choices based on our requirements. Not just jump on the latest greatest thing that everyone is talking about. If you build on WPF today, you are not really going to be blocked from doing anything you need to do. You might not get all the new shiny toys as quickly because WPF releases with the Framework every few years, whereas Silverlight looks to be sticking to an annual release cycle. But I don’t think any WPF apps are ever going to become stuck in that technology. I think as Silverlight matures even further, we will get to a place where you can just change deployment modes if you want a web based, cross-platform, security context limited version of your app and it will be what we call a Silverlight app today. If you want a deeply integrated version with the desktop you’ll choose a deployment mode that matches what a WPF app is today.

But if you are getting the feeling that you should avoid WPF because it might go away or because Silverlight is the better platform, or that WPF code will become obsolete, I think you are getting the wrong impressions and should rethink.

Tuesday, June 01, 2010 7:09:54 PM (GMT Standard Time, UTC+00:00)
Comments [15]  |