How bad is the WPF Learning Curve?

I've read and heard from several people that WPF has a pretty steep learning curve (depending on how knowledgeable or experienced you are). Seems like most people can get the demo or starter projects to work, and then find themselves getting stuck for lengths of time on miscellaneous problems. I'm curious what specifically is difficult to learn or understand (layers, SDK, XAML, data binding, etc.) and if you have any suggestions on how to avoid/alleviate some of those difficult topics?

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. https://stackoverflow.com/questions/1150173/is-it-just-me-or-is-wpf-a-mess-of-databinding-and-custom-ivalueconverters">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, https://stackoverflow.com/questions/994148/best-way-to-make-wpf-listview-gridview-sort-on-column-header-clicking">sorting listviews.

In the end, though, WPF has a lot of advantages. https://stackoverflow.com/questions/50528/font-size-independent-ui-everything-broke-when-i-switched-to-120-dpi">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 https://stackoverflow.com/questions/38428/positioning-controls-in-the-middle-of-a-checkbox">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.

It can be pretty steep.

I spent the better part of a month experimenting with WPF and writing a mock-up of our current product in it without developing an intuition for its databinding model or even figuring out how Microsoft means for it to be used. It took me much less time to grasp the basics of ASP.NET MVC.

[Our application displays/depends on a lot of real time data, and I used the Windows Presentation Foundation book by Nathan. Perhaps another book would have been more appropriate.]

WPF is easy once you get the general idea of how it works - try "WPF - how and why". The biggest problem is working out if it is worth it at all and there is still a lot of applications that would be fine implemented as Windows Forms plus a bit of graphics.

I would also agree with the earlier comment about getting into XAML - it's just like a slightly more sophisticated HTML and the only real difficulty is finding out what does what. As for getting stuck later on in a project - don't you always get stuck later on in a project? It is when you start trying to do the 1% that's tough.

It's going to be one of those 'it depends' answers but all it really depends on is if you're the kind of developer that tries to continually improve your skills. If that's the case then it comes down to a couple of things ultimately.

Buy WPF Unleashed (others books are available but I whole-heatedly recommend this one), work through the examples and in about 2 months or so you'll wonder how you ever got things done without it.

It's not rocket science and there are no paradigm shifting concepts to deal with. In fact, if you are used to keeping a good separation between your logic and presentation it should fit right in.

To get to a level of mastery you're probably looking between 6 and 12 months of playing with it.

Good luck.

Yes, it is not an easy walk - but be not afraid. The thing about WPF, it is beautifully engineered so you get a constant positive emotional feedback (at least I did ;) when learning it. You like sitting playing with it and exclaim "WOW" every few minutes ;)

From the few people I worked with that had to learn it, they really recommend going through all the tutorials from Expression Blend. That gave them a good background on WPF and the better tool to use when working with it.

If you have experience with HTML or XML or similarly based languages, it's not exceptionally difficult, especially if you have web design experience. If you're coming strictly from a WinForms background, the learning curve is a bit steeper. I am currently learning WPF myself and since I come from an extensive web development background, I'm not finding the concepts all that difficult to master for most of them. I've found the online tutorial videos at WindowsClient.net to be exceptionally helpful as well, if a bit poorly organized.