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.

About these ads

29 Responses to WPF vs. Windows Forms

  1. [...] who seems to be locked in and on the ball when it comes to WPF began a discussion today – WPF vs Windows Forms – I thought I would jump [...]

  2. [...] WPF vs Windows Forms September 5th, 2007 I see Josh Smiths has posted his view on WPF vs Windows Forms.  Here’s my current view (although I reserve the right to change it at a later date [...]

  3. Josh Smith says:

    I’ve tried to leave a comment on the “WPF vs. Windows Forms – Additional Point” post, which pinged back to this post. However, after a few failed attempts I decided to post it here instead:

    Thanks for the nice critique of my post.

    I am not sure how relevant and useful XBAP will be in general. Since it is currently limited to running only in IE6 and 7, it has no applicability outside of a corporate intranet deployment scenario.

    Within that limited usage context, it’s primary “advantage” is the fact that the XBAP deployment model is quite similar to a standard Web app. However, the fact that WPF desktop apps (not XBAPs) can be deployed via ClickOnce, I’m not sure how much benefit XBAPs actually proffer. Also keep in mind that by default XBAPs run in a security sandbox, which limits what your app can do.

    I am yet to read or hear someone explain how deploying their application as an XBAP resolved some overarching problem(s) they faced. I’d love to find out what those problems are and why XBAP was the silver bullet.

    On the other hand, I wouldn’t say that Silverlight and WPF are really that closely related. Mentioning them as two sides of the same coin is dangerously misleading, particularly considering that Silverlight v1.0 is only programmable in JavaScript!

    The functional areas in the Silverlight platform are a substantially reduced subset of WPF. I don’t expect Silverlight to really catch on until folks can use it from the comfort of a managed language, like C#.

    What I’m getting at is, in my opinion WPF is a *desktop* application platform. Silverlight, a cousin of WPF, will eventually be able to cover the Web side of the house. But I wouldn’t say that using WPF will solve any problems which Web developers face.

  4. JCardinal says:

    What I’d like to see is truly write once, run everywhere apps as full featured as winforms. That’s the killer app that Microsoft *should* be working on. I don’t care if it’s hard to do, clearly it’s coming judging by the way things are going, just not fast enough.

    XBAP is a big dissappointment when you start to look at it in any detail.

    But aside from that I’m still not sure why calling wpf “eye candy” is really all that wrong. Sure it’s very cool to look at but well, I guess you need to expand on this topic in your blog post because I’m not getting the non eye candy distinction. ;)

  5. Peter Zajic says:

    Nice post Josh,

    I think WinForms will die sooner or later. In time there will be nothing that WinForms could offer to make someone use it. It will take some time, but this era is comming ;-)

  6. Marc Clifton says:

    One of the things that I haven’t seen much discussion on (not that I’ve been actively looking) is the XML “back end” of WPF (and WCF and WF), which opens the door to what I’m doing with MyXaml and Interacx (shameless plug) with WinForms–managing the application files at the server and distributing them on demand to the client. You can easily update all your clients at once. XML also offers some interesting possibilities to create add-on customization files, so you can customize the client’s UI but leave the baseline UI “template” alone. So there’s a lot of interesting opportunities that the W… product line offers as a result of using a declarative format.

  7. Josh Smith says:

    JCardinal,

    WPF is a developer’s paradise. The platform has many features which make *programming* more enjoyable and flexible. Here are some examples:

    1) The databinding in WPF is far more powerful and comprehensive than in WinForms. This reduces the amount of code you need to write, and allows you to easily bind to pretty much anything.

    2) Routed events change the way you work with events. Now that events route down and up the element tree, there are many more ways to design code which deals with events for many controls, or controls which are loaded dynamically.

    3) Attached properties let you set a property on any object, even though the object does not expose that property. The possibilities are endless!

    4) Triggers are an extremely useful way to express conditional logic in markup. Very convenient.

    The list goes on. WPF as a platform is GREAT. And it also happens to make it easier to create “eye candy.”

    Josh

  8. Josh Smith says:

    Peter,

    I agree that WinForms will eventually die, and probably not too far from now. I disagree that in time there will be nothing it offers which would make someone use it. I mean, a lot of folks still use VB6 out there. But, I like your point and will ignore the inevitable kermudgins! :)

    Josh

  9. Odi says:

    Josh Smith wrote:

    >>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.

    Continue to be enhanced? That’s the first I heard about it. Continue to be supported, for sure, but not enhanced. Case in point: Visual Studio 2008 — no new Windows Forms control updates, new features, etc. Windows Forms is no longer evolving. All new work is being put into WPF / Silverlight, from what I can see…

  10. Josh Smith says:

    Odi,

    Thanks for clarifying that. I was under the misimpression that WinForms was still “active” in the sense the MSFT was building it up beyond 2.0. I’ve read/heard so many conflicting reports from MSFT people about the future of WinForms, that I don’t know which way is up anymore. I suppose that only time will tell what they really have in mind for WinForms.

    Thanks,
    Josh

  11. JCardinal says:

    Josh, wpf may be a developers paradise but all those points you brought up could easily be ported to winform development. I guess winform is only dead when Microsoft says it’s dead, if they chose to they could easily add the items (enhanced databinding, triggers, event routing etc) in your list.

  12. Josh Smith says:

    JCardinal,

    The “WinForms is dead” idea is from mdavey’s blog post, not mine. I’m not promoting the idea that WinForms is going away any time soon. Sure, WinForms will be around for a while, just like how people are still working in MFC and VB6 today. Most people stick with what they know, quite understandably.

    I do not, however, agree with you that MSFT could *easily* add the new features in WPF to WinForms. For example: routed events. Adding something like that to WinForms would represent a huge change to the platform. WPF does not just offer routed events, it is *based* on them. They are an intregal part of the platform, not an add-on. This same logic applies to all of the features I listed before. Tacking something like that onto WinForms just doesn’t make sense at this point.

    Thanks,
    Josh

  13. Ron Myers says:

    Josh,

    I fixed my comment system. Hope you don’t mind but I posted you comment to my post as well and responded to your points.

    My response can be found at http://unknownnamespace.com/general/wpf-vs-windows-form-additional-point/

    Cheers,
    Ron.

  14. Everyday I try to make DataGridView do my bidding, try to customize a Combobox, or subvert ToolStripDropDown/ToolStripControlHost to create a pop-up I want to switch over to WPF. Not for the eye candy, but because I want a place where OwnerDrawn isn’t a scary place to descend into, but the default, clean way of doing business.

    For now, Forms is still the default, because I know what the deployment requirements and installed base is. I haven’t really looked at what deployment requirements WPF has.

    Not sure if this exists, but it would be great if MS had a page somewhere that showed stats on the percentage of .NET distributions installed in the wild. I assume Windows Update has that data. It be nice to see what percentage of machines would likely require a framework upgrade to run a particular tech.

  15. Josh Smith says:

    Arne,

    I like this: “I want a place where OwnerDrawn isn’t a scary place to descend into, but the default, clean way of doing business.” That pretty much captures the essence of WPF! Well put.

    I’m not aware of any report which displays the distribution info you’re after.

    Thanks,
    Josh

  16. Håkan Reis says:

    Well I just want to add one thing to all this. From a developers perspective there are so many great things about WPF that it´s too easy to look at it from the user angle. The most scary part is the question you got, and especially the part “…which basically just show large tables of numbers, allow the user to sort them, edit them, etc”

    Why on earth do the developers always show the users the database? Are most of them that lazy? Basically that’s exactly what they do in most business applications. Instead, try to build in the data analysis knowledge and number handling into the logic and data model. Let the UI carry the understanding and visualization of the numbers instead of just the cold digits.

    This is, to me, where WPF comes in. Sure, at first it will be called eye candy but think of a business application that will give you the ability to spot anomalies in large amounts of numbers with just a glance, for example the stock market. With 3D you can also locate it geographically. Zoom in on the area and follow the thickest connection, to see what is causing it. Who knows, with the right analysis tools it may be possible to trace it back to the morning news.

    This would be possible with WPF but very hard with other technology. If you just let the creativity out and look at what the users need to know instead of what’s easy to display. If you are making breakfast do you want to know that the water is 373K or that if it’s ok to boil an egg?

  17. mtybwana says:

    Adam Nathan has an opinion on this topic which he states on page 15 of his book. “So unless running on Windows 98 is important … I would recommend WPF over Windows Forms for a broad range of applications — especially after Visual Studio [2008] is released. But Windows Forms isn’t going away anytime soon; there just won’t be major enhancements made to it after version 2.0 was released in 2005. Microsoft is clearly investing in WPF — not Windows Forms — as the future presentation platform.” As a member of the Microsoft WPF development team, Nathan probably has a pretty good idea of what is happening inside Microsoft.

    This tells me that it doesn’t matter whether or not Microsoft _could_ add WPF features onto Windows Forms because if they have no intention of doing so, it won’t happen. I suppose that if Microsoft wanted to it could make some major improvements to VB6 today but we all know that that will never happen because Microsoft has moved on to .NET instead. (By the way, I completely agree with Josh that there are many major features of WPF which, as a practical matter, cannot be added to Windows Forms.)

    Of course WPF hasn’t replaced Windows Forms as of today any more than VB.NET had “replaced” VB6 by December 2002. But if Microsoft offers no further enhancements for Windows Forms, unless we see a New Coke revolt from developers, WPF will be a complete replacement at some point in time.

    This gives every developer the choice today of being ahead of, with or behind the curve. To me the first option is more appealing.

    Cal

  18. Windows Vista Business system requirements

  19. Asgher says:

    As we all know that its Presentation Foundation, therefore its useless to talk about its functionality. Obviously its all about eye candy and disco lights.

    I would like to know the key fundamental features that distinguishes WPF with winforms
    please email me anything relevent.
    good luck
    man2die4@live.com

  20. peteohanlon says:

    Josh – A point that a lot of people are ignoring is that it’s a lot easier to take WPF applications beyond limitations imposed in WinForms. Not happy with the default layout? Change the theme. Targetting multiple resolutions – no problem. Want to do custom drawing? A cinch. True two way databinding – no comparison. Routed events and attached properties – oh yum.

  21. [...] WPF vs Windows Forms Posted by techjottingz Filed in C#, Visual Studio Tags: VS 2008, WPF [...]

  22. Levi Page says:

    No one seems to mention the fact that the font rendering in WPF is “horrible.” Until Microsoft fixes this problem, WPF will never have widespread acceptance.

  23. Hussein Al-Atiya says:

    Levi Page,

    You do know that you can change the font and choose the font that you like…its found in the properties window inside of Visual Studio.

    It doesnt really look “Horrible” to me..Try changing the font.

    Thanks,
    Hussein

  24. [...] WPF vs. Windows Forms (read this to get an understanding of both sides) [...]

  25. Martin Adhie says:

    Cool… have you tried loading Outlook UI clone? http://blogs.msdn.com/tims/archive/2007/06/13/wpf-hands-on-lab-build-an-outlook-2007-ui-clone.aspx

    I think rather than debating windows form and wpf, how about making interoperable component between ASP.Net and WPF? It’s same smart tag idea.

    I’ve code generator tool which allows generating those tagging in ASP.net and WPF UI, but not in Winform.
    Then wondering how if we just utilize ASP.net controls and make them available for WPF. Will have similar design time user experience.

    Instead of enhancing lots variety of controls, better just to concentrate on those common controls which used by both platform, end result it will be solid rock.

    If you interested, please drop me a mail.

    Thanks… :)

  26. Tony says:

    Even in Windows 7, the Explorer shell still appears to be written entirely in C++, and still making heavy use of comctl32.dll, and the typical WinForms widgetry that we are all quite used to. It is not that Microsoft isn’t dogfooding, but .. if the idea is to make an app that looks and feels like the OS shell, something visually consistent with all the forward/backward nav buttons, breadcrumb controls, menus, listviews, treeviews … WinForms is still hands down a viable option. It is just no longer an outward facing team at M$, so we will just have to rely on codeplex, codeproject, and the rest of the 1337 .net people out there on the internets to keep churning out those wrapper classes that we need. Does anyone remember TaskDialogIndirect?

  27. Chuck says:

    So, what would you suggest if we’re just now transitioning over to .NET? We have no WinForms or WPF experience in shop, and we know that we’ll eventually need some RIA apps delivered over the internet. Would you still suggest that we learn both WinForms & WPF, and decide which tool to use where? Or, just start from square one with WPF, and move over to Silverlight for our internet app needs (we have plenty of ColdFusion experience for our non-RIA internet apps).

  28. Josh Smith says:

    Chuck,

    I would definitely head for WPF. It’s the future of Windows client app development. If you need RIA, perhaps learn Silverlight first, and then you can leverage that knowledge when learning WPF.

    Josh

Follow

Get every new post delivered to your Inbox.

Join 284 other followers

%d bloggers like this: