Are Windows Forms old tech?

Question

It is time to write the GUI for my project, and I am wondering what technology to use. I did most of my .NET GUI development in .NET 1 & 2, so I know Windows Forms reasonably well. I am vaguely aware of WPF, but not yet attempted to "get into it".

Are Windows Forms dead or dying? Is WPF a good technology to learn? Is it the future, just a phase, or a technology that can walk hand-in-hand alongside Windows Forms?

Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?

Answer 1

Perspective from 2016:

I don't often advocate chiming in on a question this old, but thought an epilogue may be appropriate on this one. Why? Because even now (2016), I hear developers in corporate environments still asking this question.

Yes, seven years later, WinForms is still alive in corporate environments, and still supported by Microsoft. Google Trends shows a slow, steady decline in interest since mid-2005, with current interest about one-third of 2005's.

WPF made a splash about 2009, but never fully took over as the de facto standard for new UI development. Google Trends shows WPF interest peaking from 2009-2011, then declining faster than WinForms. Current search interest is about half of 2011's, but still nearly double WinForms' current search interest.

So what ARE developers using now? Web-based UIs have exploded in popularity, largely due to the rise of mobile browsing. You could argue over the best way to go about writing a web UI (AngularJS + WebAPI? ASP.NET MVC? React? All are trending upward on Google Trends). Whichever technology you use, it's hard to deny the appeal of writing a (responsive) UI once and having it work on just about all devices and platforms. Cloud hosting services furthered the push to the web by offering virtually instant/infinite scaling with low up-front infrastructure investment.

So today, I'd heartily recommend moving toward a web UI, as it may improve the shelf-life of your app--which often need to last very long in corporate environments. Alternately, if you're a Microsoft-based developer doing mobile development, Xamarin is worth a look.

Answer 2

we start using wpf in a new project we have

the new application includes a lot of legacy code in winforms.

whenever we want to use old dialog of winforms it is possible.

when you getr use to WPF you don't realy want to go back to winforms. it is just much more easy to do GUI stuff that woul take you lot of time in winforms.

any way it take some time to learn the stuff and be able to use all it's abilities (not just UI but also data binding and commands pattens).

having somone experienced that can help with first architecture can be very helpful.

Answer 3

We started using WPF for a new project and frankly, it's hard to go back to WinForms. Lots of neat stuff that I can't go withouh anymore.

One word of advice though. Even though you can do much more complex layout with WPF (like it's mentionned, a button, or almost anything really, can host other stuff like image, textbox and even more), some other 'basics' stuff found within WinForm are hard to reproduce. Example : Before the WPF toolkit came out, WPF didn't have datagrids and datetime picker, so you had to do it yourself. Also, it still doesn't have MaskTextBox, you have to do it yourself or download it from third parties. Last one I ran into which I actually find annoting is with Treeview : the lines between leaves and parents doesn't show.

That being said, still much better than WinForm on most aspects.

Answer 4

I think it's definitely worth learning WPF before it becomes more mainstream, it's always good to improve your skillset and to have experience and knowledge of newer technologies is always a plus, especially if WPF is to be more widely used in future.

Also, whilst writing xaml mark-up is very different to creating forms, it's not a million miles away from writing html and will probably not be too much of a departure for you if you've done any web development.

Whilst WinForms is an older technology that doesn't mean it will ever disappear though, we still have applications where I work that are written in VB6. Only half of our development department work with .NET - we're split into 3 teams, one team is still using .NET 1.1, another team is using .NET 2 and the team I'm on is using .NET 3.5 (you could say we're the lucky ones!)

Answer 5

Are WinForms dead or dying?

No. It is not significantly developed further (i.e. no new major additions), but it is fully supported in .NET 4, for example.

Is WPF a good technology to learn?

Yes.

Is it the future, just a phase, or a technology that can walk hand-in-hand alongside WinForms?

It is intended that you eventually move over to WPF, but it is also understood that there are large existing codebases written in WinForms, and there's no business case for rewriting them in WPF. Hence WinForms remains supported.

Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?

Broadly speaking, WPF is much more expressive. If you look at frameworks as set of Lego bricks that can be put together in various ways, WinForms bricks are much larger - each one does a lot - and therefore there are fewer ways to put them all together. Quite often, when you need something-but-not-quite like what an existing brick does, you have to write your own from scratch. In WPF, the bricks are significantly smaller, and can be combined in many interesting and even surprising ways.

For a concrete example, consider how WPF Button is a container that can host arbitrary content - not just image+text as in WinForms, but absolutely any other WPF control or set of controls.

WPF is also much easier to write dynamic layouts in compared to WinForms. The latter has layouts, too, but the problem is that they're a royal PITA to work with in visual designer, and writing WinForms component initialization by code is very tedious. With WPF, you just write XAML markup by hand, and layouts (and control trees in general) are very naturally represented in XML.

Partially stemming from the above, I find that WPF is easier to localize. For one thing, it's because you really do need dynamic layouts for localizability (since you don't know in advance the length of the strings in all locales). WinForms solution to this is to consider not only text labels, but also control position and size, as "localizable property" - so the translator is supposed to rearrange controls on the form himself if he finds that strings don't fit. In WPF, dynamic layouts are the default approach, so localizer just deals with strings.

WPF binding framework is rather powerful (even if verbose, thanks to lack of inline converters), and heavily promotes MVP, and, in general, model/view separation. This is possible to achieve with WinForms in 2.0+, and I try to do that there as well, but it's more tedious, especially with respect to null handling, and sometimes can be rather buggy.

One particular pain point is the way WinForms designer interacts with source control. There are two similar problems here. First of all, designer serializes edited form as code, and sometimes very minor changes in layout can make the designer generate completely different code (this is particularly noticeable if you edit toolbars) because it shuffles the code lines around - i.e. in reality it changed a single property value on one line, but it also reordered everything. This leads to very much noise in history (it's nigh impossible to tell what exactly was changed when looking at diffs), but more importantly, it means that merging such files is a major headache. This usually happens when two people work with the same form at the same time, and then one commits his changes, and the other one tries to commit, finds out that the file was changed in the meantime, tries to merge, sees the diffs, and jumps out of the nearest window.

A very similar problem happens when you use WinForms localizable forms, which pushes some properties to a resource file. Again, the designer very much likes to reorder property values in resource file for any trivial change, with all the same problems as described earlier.

Now as to deficiencies in WPF. A major one is that it's quite a bit more complicated, and may feel unfamiliar to someone with experience only with WinForms, VCL, VB, or other similar "traditional" frameworks. Another problem is that documentation, in my opinion, is not perfect - it usually gives a decent overview, but rarely covers corner cases, some of which can be pretty important. This is the case for WinForms, too, but there are fewer possible combinations there, so fewer corner cases as well.

There's also the issue of third-party components. WinForms had been around for a long time now, and there are plenty of those available for it, and a lot of them are very mature. WPF is comparatively young and still going through growth pains, and so do most third-party solutions for it.

One particular pet peeve of mine in WPF is the way it antialiases text - which is perceived as being of much worse quality compared to plain Windows ClearType by most people, especially on small font sizes; see this bug report for more info. This is fixed in WPF 4, but that isn't released yet, and even when it will be, chances are that you'll want to stick with the tried and true 3.5 SP1 for some time; and the fix isn't backported.

Answer 6

Here is a good blog post about WinForms and WPF. The overall idea is to choose wisely, meaning that there isn't one winning over the other. Each have a different subset of features.

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.

I personally prefer WPF because I started as a Web Developer and find the markup XAML to be more natural.

Answer 7

WinForms will probably be around for a long time to come in corporate environments. They work well enough for many purposes. Many projects are based on WinForms, and many companies will stick with that technology for the duration of projects rather than mix and match.

Having said that, WPF is the future. It is a much more efficient, much more capable UI technology and well worth learning.

WinForms and WPF can coexist in a single application. That will probably be the most common way for them to be introduced to a company (that, and small proof-of-concept projects).

Answer 8

WinForms is not dead. Google "winforms C# jobs" and you'll find plenty. WPF is the hot stuff but it's still relatively new. It won't be mainstream for another two to three years IMHO.

Answer 9

WinForms is far from dead/dying. WPF is simply a newer way to tackling the UI as it promotes things that were more difficult in WinForms. Things like separating the model behind the UI from the actual UI so it can easily be tested is a big factor.

It's definitely worth learning, but make sure to learn "the WPF way" of creating the screens rather than just fitting your WinForms-way into it. It's a different way of coding.

Answer 10

WinForms aren't dead or dying...they just can't provide the same User Experience that WPF can (without A LOT of work). They're just older technology.

WPF is a good technology to learn. It provides the ability to provide a much richer User Experience with less work.

The model for working with WPF is definitely different than WinForms. I've used both (WinForms more heavily than WPF/Silverlight) and the most difficult transitions for me were:

1. XAML, which isn't as bad if you have experience with another markup language like MXML.

2. DataBinding

3. Interface Event Handling (MouseOver effects, Timelines, etc.)

Answer 11

Certainly not.

Winforms are easier to use (Considering you don't know WPF yet) and WPF is quite a departure from the Winforms model.

If you want a simple GUI (standard form stuff) go with Winforms. If you want something a bit more flashy and have the time, go for WPF.

I'm sure there will come a point in the future where WPF is the defacto standard. But for now, I stick with Winforms if I want something quick and clean.

It's worth mentioning that a lot of applications are already using Winforms - meaning maintenance work will often crop up involving WinForms, so don't rite it off just yet.