WPF or WinForms, choose wisely

Choose, but choose wisely.WPF is all the rage (at least that's what they tell me) and it's IMHO one of the best technologies to come out of Microsoft. Still, however, companies choose to stay the course with building on WinForms. Karl Shifflett has a great blog entry on choosing WPF over ASP.NET (and great entries on WPF in general so check his blog out here). To me it's a no-brainer choosing WPF over ASP.NET, unless you're really enamored with a browser app (or forced to build one due to some constraints) and with Silverlight and XBAP (and the new features coming out shortly in Silverlight 2) building a rich interface for the web gets better and better. AJAX just doesn't cut it and is a hack IMHO.

Making the decision between WPF and WinForms however is a different story. Sure, WPF is the new hotness and WinForms is old and busted but is it the right choice? Obviously "it depends" on the situation and Microsoft is continuing to deliver and support WinForms so it won't be going away anytime soon. So what are the compelling factors to choose WPF over WinForms? Karl hints at choices of WPF over WinForms in his WPF Business Application series, but the reasons might be subtle for some. 

If you're struggling here are some reasons for choosing WPF over WinForms, and let's play devils advocate as you might have to fight for some of these.

Latest Technology

Why start new development on old technologies? There's bleeding edge (Silverlight 2 perhaps) and then there's cutting edge (WPF?) and we can probably start to talk about WinForms as legacy. Start, not come to that conclusion. WinForms development can be painful (much like moose bites) but the latest technology debate is a tough one. One on hand it's lickety-split to create WPF using the tools available today (see below) and from a development perspective WPF shines because everything is an object. The crazy hoops you have to jump through just to get an image on a button or menu are all but gone when you try embedding an object onto another one in XAML. On the flipside though, most of the large UI suites (DevExpress, Infragistics, Component One, Telerik) haven't fully completed their WPF implementations and the maturity lies in their WinForm incantations. Still, starting a new project today that might be delivered say 6-12 months from now doesn't make a lot of sense building on what some might consider legacy but as usual, you have to pick the right tool for the right job.

Mature Product

While WPF is pretty young in the eyes of consumers, Microsoft has invested 5+ years of development in it. WinForms arguably has the edge on maturity here (existing since the .NET 1.0 days) but don't knock WPF as a babe in the woods. It popped up on the R&D radar back in shortly after .NET 1.1 and Visual Studio 2003 came out and has been gestating ever since. This is a plus point if you're in a boardroom or meeting with some stuffies who think it's new and shiny but with no meat behind it. Combined with its own set of unique features, try something like UI automation and WinForms and we'll talk maturity. 10 years after WinForms was born and we're still struggling with UI automation. WPF solves this in one fell swoop, and does a nice job of it to boot.

Silverlight

WPF is based on XAML for it's definitions (both application code and UI design). Silverlight is the same because after all crunching down and serializing XML is dead simple these days. While Silverlight uses a subset of WPF for it's rendering, you can re-use a lot of what you might create in WPF and your application. This makes for building multiple UIs a happy-happy-joy-joy scenario. Too many times I've been faced with the problem of building a system for web users *and* desktop users. Too many times we've had to dumb down the web because it couldn't handle the rich experience the desktop provides, or be faced with 100k of JavaScript (yeah, try debugging that mess after a few sleepless nights) so anything has to be better than this. Silverlight lets you leverage a lot of your XAML investment you make in a WPF app and with technologies like BAML you can push the envelope even further. It's a win-win scenario for everyone and lays the smack down on Flash or Java anyday.

Tools

While we live in a domain driven design world (at least some of us do, you have come out of your cave right?) with objects and collections and tests oh my, there is still the UI to design. I'm not a huge fan of the move to CSS validated Expression Web, but I understand (and agree with) the choices Microsoft made with the model. Kicking it up a notch and delivering Expression Blend with it's integration into Visual Studio makes building WPF apps a breeze. In fact, I strongly advocate and support handing the UI design off to someone better suited to it. Let's face it, developers suck the big one at building UIs (unless it's "Hello World" with a big button and an image of Scott Hanselmans face on it) so let's let the UI designers design. Blend lets you do this by just letting the designers "go wild" as it were, without having to worry about "how in the heck am I going to hook this up later". Giving a designer a copy of Visual Studio to design a WinForm app is just plain crazy, and don't even try to convert their JPG mockups that have been signed off on into a Windows Form (been there, more t-shirts, I have a lot of them) but getting a XAML file from them just plugs right into our development environment and is dead simple to wire up to whatever back-end you have going at the time.

UI Resolution

How many bugs do you have logged on your current project that say something like "cannot see button x when my screen resolution is 800x600"? As a developer, we generally work at crazy resolutions that no sane person would run at (my current desktop runs at 1680x1050) so building forms on this just plain doesn't translate well (read: at all) to a users desktop of 800x600 or 1024x768. Buttons vanish, menu options disappear, and that oh so beautiful grid that is the lynchpin of your appplication is missing the bottom 20 rows and last 10 columns. Sure, WinForm containers and whatnot help but far too many times we forget about this and end up building things off in unseen areas of the screen. WPF doesn't solve this problem, but really helps. Not only that, we're not asking users to change the resolution or font size on their screen to see things clearly. In this day and age, users need to be able to dynamically change the system at will when they're working. I've seen users running with the extra large font theme as their eyes give out on them but apps just plain don't work well when your system font is 36pt Verdana. Look at the iPhone as an example of clever UI integration. It dynamically zooms in and out as you choose to make things readable. We need more of this on the desktop applications we build to suite the needs of users who want "to see it all" at once. WPF let's us do this with less pain than WinForms.

Databinding

WPF allows for much easier data binding through its model and this can result in faster development time. Now Unka Bil isn't telling you to go out and bind your WPF creations directly to ADO.NET models. I still live and die by Domain Driven Design so binding happens on objects (probably best through a Binding<T> adapter of your domain classes) but WPF does make it easier to do this if that's your thang.

So overall it's a better experience, both from the development side and consumer side. Again, you might have some battles to fight with Corporate to jump onto the technology band-wagon, but this is might be a battle worth fighting for. WPF is no silver bullet (as I always harp, the is no silver bullet unless you're fighting werewolves) but hopefully this will help you make a more informed choice. The choice is yours, but choose wisely.

11 Comments

  • Bil,

    Very nice post.

    I like the way you concluded it, "No Silver Bullet."

    Developers need consider all the aspects of their projects and make the best decision for their customer, company and project.

    Have a great day,

    Karl



  • @Rob: Cider is certainly less crappy in 2008 than 2005 (and actually doesn't crash [too much]) but I agree, it's a less than optimal experience. I don't agree that Blend is a non-starter. If you're just building fairly simple UIs Cider should be fine as IJW. For a more complicated UI just hand your design over to someone with those skills and a copy of Blend, then consume the output in VS. The web designer suffers from the same problem in VS but it seems to be acceptable for developers to use Expression Web over the VS designer, so why is WPF any different?

  • @Rob,

    I have to agree with Bil on this.

    I've been working with WPF since last April and hands down I'm MUCH more productive in WPF than WinForms.

    It comes down to learning to leverage the tools.

    Now, I had code my web sites with no problem and can type a good bit of my XAML code. Maybe I'm not the average developer.

    But the shear POWER that WPF delivers to developers is awesome.

    The ability to Style and write ControlTemplates in WPF has no match in any technology.

    Download Expression Blend, watch all the videos and give it some time to grow on you. I didn't feel the love for a week or two.

    I also purchased a $25 subscription from www.lyndia.com to jump start me with their tutorials.

    Best to you,

    Karl
    The Molenator

  • I obviously would be leaping to a conclusion by saying that you haven't actually tried to use WPF code in Silverlight.

    Silverlight XAML only looks like WPF but copying and pasting anything besides a trivial animation, a button or a shape will result in collasal incompatabilities because Silverlight doesn't have any UI controls that make WPF so good. Silverlight (current 1.0 release) also doesnt have data binding on which almost any WPF interface would rely. This renders the whole "WPF subset" upsell completely moot.

    ScottGu said that Silverlight 2.0 will have some UI controls, but how compatible they will be with WPF remains to be seen.

    Please, don't fall for MS' trying to "upsell" Silverlight as compatible with WPF. It is not.

  • I think WPF offers some great solutions right now, but WinForms which is what most people still use offers some decent interop between the two. I don't think anyone would argue that WPF offers a cleaner model, a lot of that is down to the use of XAML which many find XML derivatives far easier to use to describe the UI (XUL took the same approach).

    I don't think WinForms will go away anytime soon.

    I'm not sure what SL 2.0 will support, hopefully declarative data binding will be in there.

  • The question wether I could use WPF in the next version of a small business application was answered pretty fast by my users: They didn't like the blurry font and nothing would convince them...

  • My concern is that it is a big flip to a completely new technology. We have a lot of UI tools built that help us be very productive developing Win Forms. Bringing high quality to your products requires having repeatable processes used by highly skilled people. How do you get repeatable processes used by highly skilled people, when the underlying technology does not support a migration path?


    I have to admit, that my first impression of WPF, was that it was another ASP development environment, which I find to be very "dark ages". I have been at this for 35 years, and the WinForms IDE is the best development environment that I have seen, but I am still trying to justify making the change to WFP, but do not see it yet.

  • This is one person's opinion and it is very one side bias. Although he is correct in some aspects, I think we should investigate further and deeper. Unless your application requires 3-dimensional graphic or media player, using WPF over Winforms is not always a good choice.

  • "developers suck the big one at building UIs" - Uh.... speak for yourself, and 99% of MS(-employed) devs. OTOH I thank them for daily teaching (and painful reinforcement) by anti-example.

    And BTW, the argument that "writing should be left to writers" is only a few logical steps away. :P

  • George thank you people seem to forget about performance. It seems new = cool = better, yes in some, cases you should use WPF but for the majority of LOB applications winForms will serve you better. WinForms are faster at runtime and in the IDE (in VS switch from code view to form view and you will see what I mean). The fuzzy WPF fonts don’t help much and most of the enterprise application users I have seen don’t really want their buttons to be triangles or little fishes that wiggle when you click them.

  • Sir,
    I want to simply know which is better one on performance basics WPF OR
    WIN FORM, which technology is better for Bank project.

Comments have been disabled for this content.