How bad is the WPF Learning Curve? [closed]

WPF is different; there is no getting away from that.

My main advice is do not be afraid of XAML; Embrace it, that is where the power is!

Let me explain:-

For me to be productive, I prefer to write XAML in the text view as I can create the bare layout of the window in a few keystrokes. If you regularly type code then this is a very quick way to develop windows. You can then use the Visual editors to make it look pretty.

If you keep in your mind that each element of the XAML will "new" that object and that each attribute of that XAML element is a property of the object, you can think of XAML as object creation and assignments of properties. Very similar to writing code.

If you spend too much time in the visual designer then you do not get to appreciate this, and for some this will slow down the learning curve.

A recent Hanselminutes podcast may interest you.

I also advise strongly to learn early the concepts of Views and View-Models, even if you do not subscribe to all that is part of CompositeWPF as this really does help.

There is a nice article from Karsten Januszewski called Hitting the Curve: On WPF and Productivity you might find interesting:

Let's be clear: WPF comes with a curve. I've now watched a bunch of developers hit that curve. And the curve is steep. We're talking between two weeks to two months of curve depending on the developer and the level of experience/intuition the developer has. There will be moments of total mystification and plenty of moments of illumination. It is at once painful and enjoyable, if the developer delights in the discovery of a deep and well thought out UI platform. It is at once familiar and alien. There are many similarities to other UI development paradigms: styles feel like CSS, well sort of. XAML code behind feels like ASP.NET, well sort of. 3D feels like DX or OpenGL, well sort of. Routed events feel like .NET events, well sort of. Dependent properties feel like properties, well sort of. The list could go on. But admidst these (sort of) familiar metaphors there are so many alien concepts that must be mastered: control templating, storyboards, databinding come to mind immediately. It is not a trivial curve and don't expect to be productive on day 1 or even week 1 or even month 1.

It's all worth it though! ;)

The difficulty with learning WPF is not so much the API as the model. It's a very different mental model than you'd use with something like Windows Forms.

Rather than writing methods that imperatively populate a UI element, you generally data bind to properties on an object. To get complex behavior, you generally use some level of composition.

As an example, if you have a series of items you want in a list, with a piece of text followed by an image. In Windows Forms, you'd get the list and iterate it. For each item in the list, you'd create the control for the item, and the text, and add the picture, and then add the new subcontrol to the list. (Exact procedure may vary based on the type of control. You may add SubItems instead of just making one control, etc.).

WPF would handle this very differently. In WPF, at the top level, you'd declare a container object and bind it to the list.

You would then give that container a template to use to display its items. The template is basically another control, which defines the positioning of sub-elements, which are bound off of an instance of the class that the list is populated with.

It ends up with a very compositional feel, and is absurdly powerful. It's also a very different model than most developers are used to, and until you can internalize the model it's very common to run into problems trying to do things the way that you would in Windows Forms/etc.

Once you get used to the model, though, going back to other APIs is painful. Not because they're suddenly hard, but because you know how easy things can be.

As you might be able to infer from my question history, I definitely have found it to be a steep learning curve. You describe my experience almost exactly. As a full-time student (in math and physics, not software engineering) who only does WPF programming for hobbyist applications, it's been rather frustrating. I've tried creating new applications in WPF, or porting some of my old applications over to WPF, and always get stuck on some small little thing that seems inordinately hard. One thing I haven't done---basically because of time concerns---is sit down with e.g. a book or a series of tutorials and go through them step-by-step. If you're a professional developer, that might be much more doable, and might make WPF much easier for you.

The biggest thing that gives me trouble, I think, is getting my head around the Model-View-ViewModel paradigm (see e.g. this question of mine). Whereas in WinForms I could just drag and drop some stuff onto a form, mess with its properties, and hook up some events in the codebehind, now I have to think about partitioning things into view, model, and viewmodel. A lot of those codebehind events become validation rules or databinding stuff. It probably doesn't help that none of my applications are really "data manipulation" applications; that is, they don't manipulate a database of customer info or anything, where a lot of this would make sense. Instead it's more like "I want a textbox that the user enters a URI into, and I want the button that says 'Download' to only be enabled if that textbox contains a valid URI." Little things like that start getting really quite complicated; I have to think about where the URI fits in my model, where it fits in my viewmodel, hook up a validation framework, and databind properties of the button and the textbox to all these elements.

Another annoying issue is how many things are just plain missing from the framework. For example, sorting listviews.

In the end, though, WPF has a lot of advantages. The layout framework seems a lot nicer than the primarily pixel-based WinForms model. It uses modern fonts like Segoe UI, heh :P. And its compositing features are pretty awesome too, e.g. how natural it is to put an image on a button (just put an image XAML tag inside the button XAML tag, essentially); I suspect it can solve my problem regarding checkboxes with controls inside of them, too, although I haven't tried to do so yet.

I have been playing with .NET for more than 4 years, mostly Windows Forms applications. Binding is not something unknown and I try to use good practice in all my C# applications. For the past 1 month, I have been learning WPF for the job and I have to admit that it's VERY powerful but a lot harder to achieve things. You can do a lot more and achieve some cool designs with less effort but only once you know how it really works and it's hard because it's huge.

More, debugging is harder - that makes the learning more slow too. The problem I think is the IDE of Visual Studio that doesn't help much in the XAML and you rapidly miss some features of IntelliSense of C# when doing binding or other stuff that now is in a XML tag. I like it but yes, the learning curve is not smooth.