Is WPF Going Away?

Everyone asks "Is Silverlight replacing WPF?" All the buzz is about Silverlight. Many of the innovations in UI (controls, validation, navigation) are offered first in Silverlight while WPF plays catch-up.

Tim Heur wrote about it in his blog this week ... and that got me thinking about it yet again.

Official Microsoft keeps saying "No. See, we're betting on WPF ourselves." And, indeed they are; substantial portions of Visual Studio 2010 are written in WPF for example.

Let's take them at their word and assume Microsoft will keep WPF both alive and vibrant.

The better question, perhaps, is which technology is right for you?

Jaime Rodriguez offered the best comparative analysis that I've seen on the subject in his blog post of March 30th. He summarizes it as a trade-off between full features and full-trust (WPF) vs. reduced features and reduced trust (Silverlight). "Why wouldn't you leverage the full power of WPF if you could?"

That's a reasonable case. Being a guy who wants the biggest Swiss Army knife on the bock, I'm with Jaime by instinct.

On the other hand, if I listen for it, I can hear the Agilist counter argument: "Why carry the load of features and responsibilities you're not using?" And then there is the ever important matter of "Where do I find developers who are good at WPF?" If most developers are writing Silverlight, the economics lead me away from writing in WPF even if it is technically better suited for my application.

I think you have to ask "Who are the end users of the application?" If they reside outside of the sponsoring organization, it seems to me that Silverlight is the right call.

If I'm an ISV, "Silverlight" is almost certainly the preferred choice. If you absolutelly have to have access to the client hardware, I guess you'd hazard WPF. But even with all the gaps (the lack of printing in Silverlight is near the top of my list), I'd still go Silverlight and live with work-arounds if I could.

Frankly, I am through trying to convince customers that they'd be better off with smart client. That's a great way to waste time evangelizing instead of selling. It doesn't matter that WPF smart client is better or that you could deliver the product sooner in WPF. Because somewhere between 10% and 20% of your market thinks the application must run in the browser and won't let you install it. They won't fall for the XBAP either. As one sage told me: "Would you rather be right or would you rather be effective?"

Maybe you could do both at the same time? Just write one code base and skin for WPF or Silverlight as needed. They're both pretty close, right?

WPF and Silverlight programming models are getting closer all of the time. I've had decent success getting a lot of my code ... even ViewModels ... to be textually identical across the platforms. And we do have important customers who use our product to drive both ASP and WinForms client applications ... a route that is much more challenging; I might have encouraged a WPF/Silverlight hybrid if that had been an option at decision time.

But I fear such customers are relatively rare. Few folks can make a serious business case for maintaining a single code base that drives both WPF and SIlverlight. It takes a lot of energy to maintain that cross platform compatibility where it counts: in the UI and Presentation layers.

Do any of you have examples? I'd prefer real-life examples but I'll take speculative ones too.