Will Windows Forms be deprecated in favor of WPF? [closed]

by

This is partially a reasoned argument, and partially a heart-felt rant….

WinForms is based on the user32/GDI technology that has existed since the dawn of modern Windows. It is not going to go anywhere, in all senses of the phrase: it won’t get new features; it won’t get support dropped.

Or maybe it yet will. The charting API in .NET 4.0 is new and written for GDI, not WPF.

In general, Microsoft has a history with new technologies that looks like the following:

  1. Invent new API.
  2. Innovate with that API for 2 or 3 product cycles.
  3. Realize that continuing to innovate means making unreasonable concessions to backwards compatibility or having realizations that the technology didn’t originally address.
  4. Invent new API by wrapping or leaving the existing API around. The existing API doesn’t disappear, but new stuff doesn’t use it, either.

RDO -> DAO -> ADO -> ADO.NET -> LINQ to SQL -> Entity Framework, toss in some ODBC … there is a treasure trove of “dead” and wrapped technologies that are still usable and still exist today. These are data access technologies, but the same idea applies; UI frameworks last a little longer because they are the most visible areas of applications.

If I put my Nostradomus hat on, I can safely say that when .NET, oh, 6.0 is out in 2015–which sounds far away but is as close as we are to 2003–WPF will be as “dead” as Windows Forms because some other nifty managed interface will have been created that smoothes over all of the as-yet-undiscovered mistakes and inconveniences of WPF. Who cares? Everything we are yabbering about today will be deprecated by then. (Something is going to have to give in .NET 5.0 anyway because the framework is getting comically large.)

If anything, the thing that Windows Forms has going for it is that it’s based on the technology that has existed for well over a decade, and that inertia is not dying anytime soon: the browser you are typing in is using GDI, the taskbar is using GDI, your instant messaging application is using GDI, the new Ribbon control in Windows 7 is using GDI, the $60 printer sitting your desk is using a GDI printer driver, the Windows CE applications running on your phone run a port of Windows Forms and GDI, the new Event Viewer in Windows Vista is using Windows Forms, and there is a large third-party component community behind the Windows Forms platform–WPF is a very small, niche product that only exists in the managed world, which is itself smaller than its unmanaged counterpart.

To this end, I feel that all of these “WinForms vs. WPF” discussions are blowing things out of proportion; the technologies are not mutually exclusive or inferior/superior, as much as Microsoft marketing might have us believe, and Microsoft’s developers are smart enough to realize this. They are simply different and one of them happens to be older. If we didn’t consider this periodically, we would have all listened to Gartner in 2005 and stopped building Windows applications entirely and moved everything to AJAX on the Web … with our SOA interfaces … that expose an alternative REST interface … that use a TDD DDD model on that backend … abstracted from the database by an ORM.

Being so eager to abandon a technology for fear of its deprecation only assures our clients that we will maintain a constant level of inexperience and incompetence at programming software solutions.

WPF is part of the future, to be sure, but it’s not THE future. Personally, I’m on the fence to see if WPF “makes it” in the UI technology sense that previous data access technologies haven’t, although Visual Studio adopting it in 2010 is a pretty comforting sign that Microsoft is actually serious about it by dogfooding it in a flagship product.

To sum up: if you are building a LOB application, I wouldn’t feel guilty about using WinForms. If you need an advanced layout scenario, WPF interop is always available to you, just as one enhances a regular Web site occasionally with a Flash object. But for anything else, you owe it to your client to come up with a Good Reason for transitioning the whole team and shell to WPF; Windows Forms has its problems, but half the battle with any platform is knowing what the problems and limitations are, and most of the world (including Microsoft) is still learning WPF.

More Related Contents:

  1. WPF vs. Windows Forms [duplicate]
  2. How to make WPF TreeView style as WinForms TreeView?
  3. Can WPF and WinForms be mixed within an application?
  4. WPF Trigger won’t set property if set in Element
  5. WPF TabControl – Preventing Unload on Tab Change?
  6. WPF: simple TextBox data binding
  7. WPF ListView Inactive Selection Color
  8. How to change disabled background color of TextBox in WPF
  9. AutoComplete TextBox in WPF
  10. How to open a new window using MVVM Light Toolkit
  11. Where is the WPF Numeric UpDown control?
  12. UserControl’s DataContext
  13. Change Data template dynamically
  14. Is there Selected Tab Changed Event in the standard WPF Tab Control
  15. Binding WPF DataGrid to DataTable using TemplateColumns
  16. How to access datagrid template column textbox text WPF C#
  17. WPF global font size
  18. Printing a WPF FlowDocument
  19. How to Stretch WPF Tab Item Headers to Parent Control Width
  20. TabControl with Add New Tab Button (+)
  21. WPF: How to display an image at its original size?
  22. WPF binding with StringFormat doesn’t work on ToolTips
  23. Adding a Merged Dictionary to a Merged Dictionary
  24. MVVM binding command to contextmenu item
  25. ItemsControl ItemTemplate Binding
  26. DragDrop – DragEnter/DragLeave Events keep firing
  27. how to close a WPF Dialog Window when the user clicks outside it
  28. typesafe NotifyPropertyChanged using linq expressions
  29. Force redraw before long running operations
  30. How do I dynamically generate columns in a WPF DataGrid?

Leave a Comment