10 reasons to switch to WPF

WinForms still coexists with WPF in .NET Framework and Visual Studio. Despite the fact that it is still used, it starts to become quite outdated. I remember Josh Smith once mentioning that WPF was not intended to replace Windows Forms. Maybe it wasn’t, but it certainly makes big steps that way.

Just look at the progression – since its start, not really a lot of developers took it as seriously as WinForms – after all, WPF was about eye candy and that was the first impression after seeing the existing documentation and presentations. But it wasn’t only for that. Today, WPF is the base for lots of different products, including Yahoo Messenger and Visual Studio (believe it or not, Visual Studio 2010 is based on WPF).

So what would be the possible reasons to switch to WPF from WinForms if you didn’t yet decide to do so? I tried to outline 10 most important ones, and it is up to you whether you think these are valid points or not. It just comes from my own experience and all I can say is that I am glad I made the switch.

1. Data binding

WinForms is not even close when it comes to binding capabilities. Trust me, when you experience what is binding in WPF (how explicit and efficient it is, to be specific), you won’t be able to really go back to WinForms without looking at what WPF can do. It is pretty cool to bind controls to collections, properties and other controls’ properties by simply creating a DependencyProperty instance and use some XAML properties to correctly bind to object.

2. UI customization & graphics

Of course, this might not be your first priority, but in WPF every single UI component is highly customizable. You can completely rewrite a controls’ look and behavior by simply editing or altering its XAML template. This introduces the concept of look-less controls, where the UI is strictly separated from the logic of the control. Therefore, while the actions the control performs remain the same, the developer is able to customize its look as much as he wants. The support for graphics is way more advanced in WPF, giving the developer the possibility to work with 3D objects and shapes, animations and media in a bit of an easier manner – also through XAML (no that you aren't able to do that in code in a WPF application). Speaking of which, every element in a WPF application is a vector object, therefore zooming in and resizing can be performed without loss in visual appearance quality.

3. Clear separation between the UI and logic

The UI is designed separately and the code is structured separately. But isn’t it the same you did in WinForms? You designed the form using the visual designer and then you typed the code for each event and method. That is true, however, WPF relies on a bit of a different paradigm. In WinForms, even when you used the visual designer, there was layout code generated in the language of choice (for example - C#, VB.NET, or C++) for the Designer.extension part of your form. You could not design the form separately without actually having that code – this means that you had to know the language in order to build the UI. In WPF, the UI is based on XAML – extensible application markup language. Using XAML, you can design a specific UI without knowing what language it is going to be used with – either C# or VB.NET. Therefore, the entire UI design can be done (not necessarily) by a person who is not aware of the programming language that is going to be used (even a person who has no programming language knowledge whatsoever).

4. Easier implementation for the MVVM pattern

Knowing that the UI is strictly separated from logic, it is pretty common to implement the MVVM pattern (Model – View – ViewModel) in WPF applications. Implementing this pattern in a WinForms application will require a bit more work on the binding layer, while WPF has the needed functionality built-in. All you need to do is to properly design the architecture for your application and implement the three pattern elements.

5. “There is no control for that” no longer applies

When WPF just started, a lot of developers were saying that the main reason they don’t like WPF is because of the lack of user controls that can be used in WPF applications. Although this was only partially true (since most of them were referring to third-party controls) – most of the controls in the WinForms toolbox are accessible through WinAPI. There are literally hundreds of third-party WPF controls available, so this argument is no longer a reason to stay on WinForms.

6. The visual designer got much better

As much as I don’t like relying on visual designers, yet another problem that was attached to WPF from its early stages was the actual visual designer that was often slow and was lagging when there were a lot of controls used on the window or the page. Compared to what WinForms had at that time, it was true that the WinForms visual designer offered much better performance and reliability. Since then, the Visual Studio team improved the WPF visual designer so much, that you can barely see any difference, performance-wise. It might take some time to get used to the way it is organized, since the window layout is organized a bit differently, but there are no longer issues like there were a while ago. Besides, you can always use Expression Blend if you don’t like the visual designer in Visual Studio.

7. Ability to run in the browser

A WPF can run inside the browser through XBAP and access a lot of Windows functionality as long as it’s a full-trust application. This gives you the ability to host the application on a remote server and let your clients access it no matter where they are, as long as they have the proper version of .NET Framework installed.

8. Microsoft firmly switched its focus on WPF

If you look at the improvements that were introduced for WPF and those for WinForms, you can see that Microsoft is re-focusing its development plans to push WPF as the replacement for WinForms. In the latest release of Visual Studio, there were lots of improvements in WPF and Silverlight, while WinForms was standing aside. Taskbar support (jumplists, progress bar in the taskbar, overlay icons), support for touch input, Pixel Shader 3 support - all these were introduced in WPF, but not in WinForms. Platform support and active development is an important factor in deciding which sub-framework to choose. So far, WPF is in the lead.

9. Support for pages

Now your application can not only run based on separate windows, but also pages. This is especially useful when there are various levels segments that require user input and visualization, since pages offer easier navigation between content.

10. Strong ties to Silverlight

Although WPF and Silverlight (previously codenamed WPF/E) are two separate technologies, they share some of the architecture principles and the XAML layer. Therefore, if you have enough experience with WPF, you can easily star working with Silverlight with slight adjustments and vice-versa.

Of course my list is in no way a final set of reasons – I am pretty sure that there are people out there who can list tens of other reasons to make the switch, others will try to provide arguments that the switch is not worth it. At the end, though, WinForms becomes outdated while WPF is advancing. The sooner you make the switch, the more potential you are giving your applications.