none
WPF vs. Windows Forms

    Question

  • Lately I have been doing some research into WPF and Windows Forms and trying to find out which one is the best to use. I have been trying to find information and have found articles / blog entries / and forum threads which pretty much contradict each other.. I can understand that people are advocates for one approach but what i am trying to do is create an objective view about the pros and cons about each technique.

    Please understand that I'm a newbie in both, and that i'm only trying to learn from this. Feel free to add to the list, I am very interested in your comments.

    WPF vs. Windows Forms

    WPF
    + Powerfull styling and skinning structure
    + Easy to create an own Look and Feel
    + Does support Windows Forms
    + The future technology for developing Vista Applications
    + The ability to reuse existing code
    + Highly advanced databinding possible
    - Declarative vs procedural code
    - Requires .NET Framework 3.0
    - Compared to Windows Forms, still in development fase
    - Requires Dx9 compatible vidcard for advanced graphics

    Windows Forms:
    + Extensive documentation to be found on the internet
    + Plenty of examples
    + Does support WPF
    - How long will this be supported? (I've read somewhere that Microsoft is only developing WPF now, only maintanance for Winforms)
    - Design your own look and feel in a application is a lot of work.
    Tuesday, December 18, 2007 9:40 AM

Answers

  • Hi,

     

    - Declarative vs procedural code

     

    I would say that was a +, not a -. If there is a declarative approach to doing what I want, I will favour it over procedural code. Declarative approaches can be inflexible, but the "code-behind" nature of WPF means that you can cover a lot of ground robustly in a declarative style, and plug the gaps procedurally.

     

    - Compared to Windows Forms, still in development fase

    Thats not true - .Net 3.0 is released for one year now. However, WinForms certainly benefits from being in v2, and there are plently of 3rd party controls to help out too, but both are released technologies.

     

     

    You need to look at what you are going to be developing, and use the forms package that offers the best advantage. If you need to turn out data-centric business for in house use at your employer, the WinForms probably offers speedier development that WPF. If you are building apps where distinctive look and feel, and creating a superior user experience are real goals, then WPF is probably a better choice.

     

    When these two are compared, seldom is any mention of ASP.NET made. I guess the difference between web and desktop apps is more profound than the differences between desktop forms packages, althougth users generally ony care about the end result. Anyway, with Silverlight 2.0 on the way, the WPF way of doing things bridges this gap, and I think this alone is reason enough for any .Net developer to learn WPF.

     

    Regards,

    Nick.

    Tuesday, December 18, 2007 10:21 AM
  • I whole heartedly agree that declaritive is a plus, not a minus.  I've used many different UI technologies, and by far the best approach has been declaritive: HTML, XUL, XAML.  Non-declaritive approaches are harder to design with: Win32, MFC, VB Forms, WinForms.

     

    I have to agree with the original poster, to some extent, on the second point.  Yes, WPF is released, and has been for a year, but it's still far from a mature API.  There's lots of dark corners in the design that will, I'm sure, be improved upon in the future.  There's also a lot of things one would expect in a mature UI library that don't exist (just one simple example is a date picker).  None of this prevents you from using WPF very effectively, but if you're not willing to put in some effort, the maturity of the API is definately worth considering.

     

    That said, I'm not convinced that data-centric business applications are clearly WinForms fodder.  The data binding in WPF is very compelling for this sort of application.  The lack of a few key control types means you have to either roll your own or acquire third party components, but in the end this is still a great platform for data-centric business applications.

    Tuesday, December 18, 2007 12:55 PM

All replies

  • Hi,

     

    - Declarative vs procedural code

     

    I would say that was a +, not a -. If there is a declarative approach to doing what I want, I will favour it over procedural code. Declarative approaches can be inflexible, but the "code-behind" nature of WPF means that you can cover a lot of ground robustly in a declarative style, and plug the gaps procedurally.

     

    - Compared to Windows Forms, still in development fase

    Thats not true - .Net 3.0 is released for one year now. However, WinForms certainly benefits from being in v2, and there are plently of 3rd party controls to help out too, but both are released technologies.

     

     

    You need to look at what you are going to be developing, and use the forms package that offers the best advantage. If you need to turn out data-centric business for in house use at your employer, the WinForms probably offers speedier development that WPF. If you are building apps where distinctive look and feel, and creating a superior user experience are real goals, then WPF is probably a better choice.

     

    When these two are compared, seldom is any mention of ASP.NET made. I guess the difference between web and desktop apps is more profound than the differences between desktop forms packages, althougth users generally ony care about the end result. Anyway, with Silverlight 2.0 on the way, the WPF way of doing things bridges this gap, and I think this alone is reason enough for any .Net developer to learn WPF.

     

    Regards,

    Nick.

    Tuesday, December 18, 2007 10:21 AM
  • I whole heartedly agree that declaritive is a plus, not a minus.  I've used many different UI technologies, and by far the best approach has been declaritive: HTML, XUL, XAML.  Non-declaritive approaches are harder to design with: Win32, MFC, VB Forms, WinForms.

     

    I have to agree with the original poster, to some extent, on the second point.  Yes, WPF is released, and has been for a year, but it's still far from a mature API.  There's lots of dark corners in the design that will, I'm sure, be improved upon in the future.  There's also a lot of things one would expect in a mature UI library that don't exist (just one simple example is a date picker).  None of this prevents you from using WPF very effectively, but if you're not willing to put in some effort, the maturity of the API is definately worth considering.

     

    That said, I'm not convinced that data-centric business applications are clearly WinForms fodder.  The data binding in WPF is very compelling for this sort of application.  The lack of a few key control types means you have to either roll your own or acquire third party components, but in the end this is still a great platform for data-centric business applications.

    Tuesday, December 18, 2007 12:55 PM
  •  

    How long will this be supported?  - From what I've read, Microsoft is not shelving forms, but will continue to support and increase forms capabilities.
    Tuesday, December 18, 2007 4:12 PM
  • Thanks a lot of your comments. What I should have mentioned, that I am planning of using WinForms / WPF to rebuild certain components in an excisting application. So some of the things you mention are actually cons for me. But thanks anyway for your help and I want to encourage others to keep adding to the list!
    Wednesday, December 19, 2007 8:20 AM
  •  

    WPF vs. Windows Forms

     

    Note WPF can host windows user controls and visa versa  however if this is done for a large amount of controlls i do see performance suffer,  also it will create more weird problems.



    WPF
    + Powerfull styling and skinning structure

    + Easy to create an own Look and Feel
    + The future technology for developing Vista Applications
    + The ability to reuse existing code
    + databinding works and is simple . Highly advanced databinding possible

    + Much quicker to develop normal apps .  ( Forms is probably quicker for v simple apps) - once you are experienced,
    + Declarative vs procedural code ( You can use Procedural if you want)

    + Requires a lot less code behind to do common things. Framework much smarter.

    + Much more maintainable apps (from better databinding and declarative code with better seperation) . 

    + Excellent layout

    + Excellent document support.

    + Multi media support.
    - Requires .NET Framework 3.0
    - Compared to Windows Forms, still in development phase (?? not sure about this - sure some controls are missing ( calander/datetime) but the framework is miles better
    - Requires Dx9 compatible vidcard for advanced graphics

    - Considerable learning curve .

    Windows Forms:
    + Extensive documentation to be found on the internet
    + Plenty of examples

    + Many mature 3rd party controls available

    + Very quick to develop simple data bound applications  ( eg a single form with a grid) , once you get to master detail WPF probably better.

    + Easy to get started.
    - DataBinding is a pain in the butt.. Ok for simple scenarios but when your client wants something a bit out of the norm you will end up pulling the bindings out and do it manually,
    - How long will this be supported? (I've read somewhere that Microsoft is only developing WPF now, only maintanance for Winforms)
    - Design your own look and feel in a application is a lot of work.

    - Cant do advanced graphics
    - Compared to web components and WPF relatively feature poor though mature. Most of the code is just wrappers around the Com UI objects. Which can lead to very painfull problems.  Extending it is much more painfull than WPF .

    Regards,

     

    Ben

    Tuesday, February 19, 2008 5:37 AM

  • WPF
    + Powerfull styling and skinning structure

    + Easy to create an own Look and Feel
    + The future technology for developing Vista Applications
    + The ability to reuse existing code
    + databinding works and is simple . Highly advanced databinding possible

    + Much quicker to develop normal apps .  ( Forms is probably quicker for v simple apps) - once you are experienced,
    + Declarative vs procedural code ( You can use Procedural if you want)

    + Requires a lot less code behind to do common things. Framework much smarter.

    + Much more maintainable apps (from better databinding and declarative code with better seperation) . 

    + Excellent layout

    + Excellent document support.

    + Multi media support.

    + Vector Graphics simplifes painting Operations

    + 3D

    + Animations

    + WPF Everywhere Idea (Silverlight and Microframework)

    - Requires .NET Framework 3.0
    - Compared to Windows Forms, still in development phase (?? not sure about this - sure some controls are missing ( calander/datetime) but the framework is miles better
    - Requires Dx9 compatible vidcard for advanced graphics

    - Considerable learning curve .

    - Complexity


    Windows Forms:
    + Extensive documentation to be found on the internet
    + Plenty of examples

    + Many mature 3rd party controls available

    + Very quick to develop simple data bound applications  ( eg a single form with a grid) , once you get to master detail WPF probably better.

    + Easy to get started.
    - DataBinding is a pain in the butt.. Ok for simple scenarios but when your client wants something a bit out of the norm you will end up pulling the bindings out and do it manually,
    - How long will this be supported? (I've read somewhere that Microsoft is only developing WPF now, only maintanance for Winforms)
    - Design your own look and feel in a application is a lot of work.

    - Cant do advanced graphics
    - Compared to web components and WPF relatively feature poor though mature. Most of the code is just wrappers around the Com UI objects. Which can lead to very painfull problems.  Extending it is much more painfull than WPF

    • Proposed as answer by Rohan Kalra Tuesday, March 23, 2010 12:40 PM
    Saturday, March 08, 2008 9:50 PM
  • Here is my blog post regarding WPF vs. Windows Forms, from control authoring perspective:
    http://www.devzest.com/blog/post/WPF-vs-Windows-Forms-From-Control-Authoring-Perspective.aspx

    The same concept applies to application development as well.
    WPF Docking | Open Source WPF SplitContainer
    Tuesday, August 25, 2009 5:54 AM
  • Your comparison is quite nice. I just wrote a blog about this topic.


    http://geekatwork.wordpress.com/2010/03/09/wpf-vs-windows-form/


    In my oppinion, Windows Form is still more popular at the moment, but WPF is the only future.
    Wednesday, March 10, 2010 9:51 PM
  • You are quite right!

    I just started with WPF about a week ago (comming from WinForms). I really like the new Frame work, but there still is a lot of work needed by Microsoft to make it WinForms equal.

    One point is, that a LOT!!! of functions, that I am used to in WinForms, one very important one being menu merging, is not available in WPF. Shure, yout could code something to do that task for you, but that is in my opinion a step back towards stone age.

    Also, a lot of controls, such as the simple numeric updown control is missing in WPF. As with the last point, you can code one, but this is a step back as well.

    Last but not least is XAML a PITA! Even the old declarative "Language" for coding native Windows API Forms is easier. With all that and no really feasable designer at hand (no, expression blend is not that good either), it is rather hard to do more than just putting some buttons together and giving them a fresh look.

    Certainly, when these points are all addressed, it would be a great framework! But to be honest, since MS didn't upgrade the designer in VS2010 very much and didn't add the missing functionalaty in .net 4, I don't know if they ever will. And if they don't, WPF is a dead framework for me. Until they make some major changes in the framework and tools that allow usability as easy and widespread as in WinForms, WPF is not a feasable solution for any programmer, that doesn't have to use the advanced features it provides.

    Saturday, October 02, 2010 8:16 PM
  • You are quite right!

    I just started with WPF about a week ago (comming from WinForms). I really like the new Frame work, but there still is a lot of work needed by Microsoft to make it WinForms equal.

    One point is, that a LOT!!! of functions, that I am used to in WinForms, one very important one being menu merging, is not available in WPF. Shure, yout could code something to do that task for you, but that is in my opinion a step back towards stone age.

    Also, a lot of controls, such as the simple numeric updown control is missing in WPF. As with the last point, you can code one, but this is a step back as well.

    Last but not least is XAML a PITA! Even the old declarative "Language" for coding native Windows API Forms is easier. With all that and no really feasable designer at hand (no, expression blend is not that good either), it is rather hard to do more than just putting some buttons together and giving them a fresh look.

    Certainly, when these points are all addressed, it would be a great framework! But to be honest, since MS didn't upgrade the designer in VS2010 very much and didn't add the missing functionalaty in .net 4, I don't know if they ever will. And if they don't, WPF is a dead framework for me. Until they make some major changes in the framework and tools that allow usability as easy and widespread as in WinForms, WPF is not a feasable solution for any programmer, that doesn't have to use the advanced features it provides.


    that's pretty much the answer I was looking for.  Someone who's providing a real assessment of what to expect if moving to WPF.  Thanks
    Application Developer
    Wednesday, November 10, 2010 6:18 AM
  • Perhaps I'm influenced by having experience with web development but I like XAML.  I see it as a huge plus rather than a PITA.

    Having recently had to do some winforms development I was quite surprised that there wasn't so much info on the web about it as I recall.  Back in 2003-5 there were more sites about winforms and more books.  Now I think it's easier to find more info on WPF.  That's my impression anyhow.

    Wednesday, November 10, 2010 8:50 AM
    Moderator

  • As a new WPF developer, coming from a winforms background, I've got to recommend just biting the bullet and going with WPF and the MVVM model ...
    I'm working on a real-time application that has as its data model a stream of data arriving every 200 ms.
    It has to present this data graphically and also allow the user to make configuration changes using various controls on screen.

    I read a couple of articles on MVVM and also downloaded some video tutorials on WPF+MVVM from microsoft.
    I did miss the numeric updown but to implement your own updown is really trivial using a simple WPF user control in XAML.

    The main advantages of WPF I've seen so far are user controls, binding, animation, dependency properties and the whole MVVM thing ...
    these are huge improvements and for me have been a revelation ... like going from the dark ages to the 21st century of UI development!

    Thursday, November 11, 2010 12:03 AM
  • To be honest, this post seems to confuse more than provide a solution to understand which framework or technology is better :) . As far as my understanding is concerned, i started developing a simple register maintenance application using WPF few days back using samples and other stuff. The main difference i found is absence of many many contols of WinForms. XAML is fine and doesn't take much time for understanding. 

    But for native Winform developer, i dont see much point in moving to WPF if there application doesn't center around high-design interface. And from my prespective the 3D rendering and all other high design tricks dont appeal in a real world application. I checked out the Hospital Sample application made in  WPF provided by Microsoft. Sure it looks fine for the first time, but when deployed and used full time creates a headache.


    RD Invent (Dynamic Solution for Dynamic Business) Professional Web development company Visit Website
    • Proposed as answer by Kasper M T Friday, January 02, 2015 1:38 PM
    • Unproposed as answer by Kasper M T Friday, January 02, 2015 1:38 PM
    Monday, December 27, 2010 8:07 AM
  • This thread is about three and a half years old but I want to add a couple of things anyway.

    I am reading a book about WPF and it is saying essentially the same thing as "Easy to create an own Look and Feel" but it is not clear what that means. I hope the book (later) explains WPF well enough that I understand why WPF is considered to make that easier to do.

    One thing that developers seem to overlook is that Windows Forms is built upon Windows more directly than WPF. This is both an advantage and a disadvantage. To the extent that Windows is poorly designed, Windows Forms suffers from that poor design. I also get the impression that Windows Forms was designed by VB programmers that did not understand the advantages of object-oriented programming, and to the extent that that is true, I can understand Microsoft abandoning Windows Forms.

    I think that many developers get the term "supported" confused. Not supported typically means that something won't be fixed if it is broken. An absence of improvements however does not mean that something is not supported. There are many things that can be done using the Windows API that is not yet available in Windows Forms but generally speaking there is not many improvements in the UI portions of the Windows API yet the Windows API UI is still very supported. (This however might begin to change in September.)

     



    Sam Hobbs
    SimpleSamples.Info
    Saturday, July 02, 2011 11:08 PM
  • "Easy to create an own Look and Feel"

    In wpf, controls are lookless.  What's that mean?  It means they can be styled to look any way you want.  So if you want round buttons then you can make them round.  You can also style theme and  re-skin an application relatively easily.  Whack a style targetting all buttons into app.xaml and all buttons will now default to that definition.

    Plus, the way binding and commands etc works it's easy to separate concerns.  So you can put together a form and viewmodel which are independent of one another.  A bit of training on Expression Blend and your graphics guy can completely alter the look of your form.  What's more everything can still work without the graphics guy learning to code.

     

    "One thing that developers seem to overlook is that Windows Forms is built upon Windows more directly than WPF"

    I don't follow that.

    DirectX is part of windows.

     

    With win8 it sounds like the fundamentals of the win32 api are being replaced.

    I'm not entirely sure what that means for winforms in the long term but if excel still works on win 8 then I would think most winforms which don't have any p/invoke in them will still work.

    Monday, July 04, 2011 8:12 AM
    Moderator