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.