Why use WPF if it is not RAD yet?

I have been heavily involved with WPF for years now. When I first started out with “Avalon” it was hardly a blip on the .NET radar. After just a couple of years the crickets have been replaced by a rock concert, and the intensity just keeps growing. For a WPF geek, such as me, this is great news!

My numerous encounters with people using WPF have lead to me to conclude that the platform is finally gaining traction in the .NET universe. WPF has been picking up momentum for a while in the financial services world, in particular. I have also met quite a few people using WPF in the state/local government sector, the retail sector, entertainment sector, and quite a few others.

But, wait a minute…why are people moving to WPF? Visual Studio 2008 offers rather weak design-time support for WPF. The lack of drag-and-drop magic in VS2008 essentially kills any hope of the rapid application development (RAD) that so many software shops hold near and dear. Why are people leaving RAD for MAD (manual application development)? In this blog post, we will discuss why WinForms and ASP.NET developers have decided to move on to WPF. Note, everything in this post is based on discussions I have had with people, but is certainly not the “definitive” explanation by any means.

The most obvious reason that people are now moving to WPF is that Visual Studio 2008 natively supports WPF development without requiring any extensions to be installed (i.e. the Orcas extensions for VS2005). Even though the WPF design-time experience still leaves much to be desired, the fact that it is part of VS2008 is important for many software shops. Most companies simply will not base their software development on pre-release bits; and I do not blame them.

In the previous paragraph, I mentioned that Cider (the WPF designer in Visual Studio) leaves much to be desired. Compared to the high-productivity RAD tooling support to which Windows Forms and ASP.NET developers are accustomed, it might seem surprising that anyone would drift away into the not-so-RAD world of WPF. Let’s take a closer look at exactly what this means.

Moving from ASP.NET to WPF is not too radical of a shift (so I’ve heard), in terms of tooling. Both platforms involve a markup file with an associated code-behind file. In both ASP.NET and WPF, the developer expects to go into the markup file and tweak the tags by hand. The design surface can only get you so far. From a tooling perspective, the shift from ASP.NET to WPF is not as radical of a change as for WinForms developers.

For those of us who approach WPF with a strong background in Windows Forms, however, you are pretty much required to remove your brain from your skull, rotate it 180 degrees, and put it back in.

This stems from the fact that WinForms developers are trained to never look at the designer-generated muck that is written for the Forms that they whip together in VS. The idea of working with markup that represents a UI is foreign to most WinFormers. Trying to move from a world where the serialization format used by Visual Studio to represent a UI is irrelevant, into a world where you are hand-coding XAML to get a UI together represents a significant mental shift.

This brings us back to the original question. Why are people moving to WPF at an increasing rate? I have heard several recurring themes when I ask people this question. Below I summarize each theme, and try to explain the rationale behind them.

Many people who moved from WinForms to WPF have told me that they are concerned about Microsoft gradually phasing out WinForms and concentrating their new developments and customer support into WPF. Many people feel that sticking with WinForms is just asking to be left in the dust. That is a very forward thinking idea, though I obviously have no idea how long it will be before WinForms is retired.

Another common theme I have noticed is that people are leaving WinForms for WPF because they want to incorporate advanced data visualizations in their programs. There seems to be quite a lot of interest in the possibilities of charts and graphs that a vector-based rendering system, which supports 3D, has to offer. Creating animated 3D data visualizations in WinForms is not exactly something that the average developer can do, but in WPF the barrier to entry is significantly lower. In my mind, that’s a very good thing (unless you happen to be making excellent money by creating advanced 3D data visualizations via GDI+).

The other common thread I’ve noticed is that people move from WinForms to WPF because they find certain aspects of the platform appealing. For example, many folks I meet tell me that the WPF data binding system alone was compelling enough for them to make the switch. I completely understand that!! From a developer’s perspective, things like triggers, routed events, rich data binding, and commands are extremely useful and addictive.

The last thing I have heard people say, but not quite as often, is that they want to have an easier way to involve a Visual Designer in their project. People who say that are typically working on a product, as opposed to an internal application for a company. For them, the idea that their aesthetically-challenged developers will not be responsible for designing the user experience is a powerful selling point for WPF adoption. Once again, I completely understand that! 😉

The reasons why ASP.NET folks are moving to WPF overlap with the reasons listed above, for WinFormers. In addition, I have heard that some Web developers are just plain sick and tired of dealing with browser-incompatible HTML and CSS. I have met Web devs who originally got into Web programming because it made the deployment of their applications much simpler. They soon discovered that they traded the simplicity of development for simplicity of deployment. Pick your evil…

The other major reason that I hear of ASP.NET developers getting into WPF is so that they can get a jumpstart on Silverlight. Since Silverlight is planned to be a subset of WPF, many people find value in learning WPF now, so that they can apply that knowledge to Silverlight once it is officially released. I think that is a very wise plan.

What about you? Why have you started using WPF, or not? What are the key factors in your rationale for adopting or avoiding WPF?