WPF vs. Windows Forms

During my WPF presentation at the NYC .NET Developer Group, someone asked me a simple yet difficult question.  Allow me to paraphrase: “I work for a bank’s IT department.  We build Windows Forms applications which basically just show large tables of numbers, allow the user to sort them, edit them, etc.  There is some simple business validation in place, and a few other standard LOB-application things you’d expect.  We have no need for UI candy, animations, 3D, etc.  Why should we use WPF and what can I say to management to convince them that we should use WPF in upcoming projects?”

When he asked that question, I did not have an answer for him.  Ever since that night I have been thinking about it, and even had the chance to discuss it with Tim Sneath; who had some excellent perspectives on the question.  Here is my much delayed answer for the fellow who asked that question.  Please note that the answer I’m about to give does not necessarily reflect Tim Sneath’s opinion of this topic, nor am I claiming that he supports the view I’m about to express.

WPF is not intended to replace Windows Forms.  I used to think it was intended to be a replacement for WinForms, but it is not.  WinForms is still alive and well, and will continue to be enhanced and supported by Microsoft for years to come.  WPF is simply another tool for Windows desktop application developers to use, when appropriate.  If the type of applications you develop would not benefit from the features found in the WPF platform, then perhaps WPF is not the correct platform for you to use. 

So when should one use WPF instead of WinForms, and vice versa? 

First off, WPF is not just for applications which simply require “eye candy.”  That is the most common and frustrating misperception about WPF which I’ve encountered.  Sure, WPF has a lot of support for flashy visuals and animations.  But that’s not all it’s good for.  If you’ve worked with WPF for any substantial period of time you are probably well aware of this fact, so I won’t keep harping on the issue.

WPF is an especially great platform to use if your applications involve various media types.  For example, if you need to incorporate video, or documents, or 3D content, or animated transitions between a sequence of images, or a combination of any of the above.  WPF is also great if you need to create a skinned user interface, or if you need to bind to XML data, or dynamically load portions of a user interface from a Web service, or want to create a desktop application with a Web-like navigation style.

Another great reason to use WPF is if you have a team of developers who are bored with WinForms and are itching to get into something new and cool.  Of course this is not as powerful and compelling a reason from a business perspective, but nothing promotes employee retention better than keeping the employees interested in their jobs.

WinForms definitely still has a role to play, despite the fact that WPF has hit the scene.  If you are building applications with no need for the extensive modern functionality in WPF, then there is no compelling reason to leave behind a time-tested developer-approved platform.  WinForms certainly has more 3rd party controls available, online resources, developer communities, etc. than WPF currently does.  It’s much easier to find WinForms developers than WPF developers.  Also, WinForms currently has a much better design-time experience in Visual Studio than WPF.  That fact alone is a very compelling reason to stick with WinForms for a while.

Lastly, don’t forget that it is possible to use WPF controls in a WinForms app, and WinForms controls in a WPF app.  If you have a substantial investment in a WinForms code-base, but want to use some aspect(s) of WPF, you can leverage the interop support to make that possible.  Just be sure to read up on the limitations involved with WinForms-WPF interop before getting too far down that path.