5 Reasons why I hate WPF

I decided to use writing a new tool as a way to learn WPF and MVVM and I thought I’d write down a few of my problems as a way of cathartic release.

I decided to read a book before attempting WPF for the first time as I’ve heard others complain about the steep learning curve. I chose the rather excellent “WPF 4 Unleashed” by Adam Nathan to read through and “Pro WPF in C# 2010” by Matthew MacDonald as a reference whilst I programmed.

1 – Poor editing support for XAML

The first thing I think any developer is going to notice about starting with XAML is that the visual studio designer is pretty poor (choosing my words carefully). I liken it to using the experience using Word to edit HTML documents. Really you have no choice but to hand code it if you want anything even roughly resembling something maintainable xaml. Even then the designer doesn’t give the best of previews e.g.


Why no scrollbars?

2 – Poor editing support for Graphics

Next up comes what is a strength of WPF, the vector graphics. Now don’t get me wrong I like vector graphics just the tool support at the moment is terrible. The only bright ray of hope is Inkscape which will allow you to trace a bitmap to convert it into vector and also export xaml files.

I found this helped somewhat but still the output wasn’t very clean and for simpler graphics like the arrow or the tick I just resorted to drawing on graph paper and typing the ever so user friendly PathGeometry directly.

<PathGeometry x:Key=”DatabaseShape”
Figures=”M 150,100
L 150,250
Q 150,280 225,280 S 300,280 300,250
L 300,100
Q 300,80 225,80 S 150,80 150,100
M 150,150
Q 150,170 225,170 S 300,170 300,150
M 150,200
Q 150,230 225,230 S 300,230 300,200″
FillRule=”Nonzero” />

Yes, I coded this by hand.

3 – Blurry bitmap appearance

Now for another drawback when favouring vectors. I’m not a purist and am regularly accused of committing coding horrors however, Dear Microsoft, Please support just showing a bitmap at normal resolution without resorting to blurring it. I will get images and I can’t spend the time converting everything to vectors so sometimes I just want to show a bitmap without having to swallow a whole bottle of Kool-Aid.

It amazes me that WPF doesn’t include this ability as standard.

4 – Changing appearance of standard control

Is it a good or a bad thing that in order to change some relatively minor appearance of a standard control you have to copy the whole control template into your project and modify it? I really miss the ability to just change behaviour or appearance slightly with a cleverly constructed sub-class in winforms.

To me it just seems a little heavy-handed and I really hope there must be a better way of doing things that I’ve just not found in my initial investigation.

5 – Hard Trivial – Trivial Hard

I can’t remember the exact quote but it went something like.

“WPF makes the hard trivial and trivial hard”

If you want your application to contain lots of custom drawing, drop shadows, blended backgrounds and an almost CSS like way of designing the UI’s then WPF and MVVM is fantastic. However if you want to show a modal dialog box – beware!!! Why? I mean the Kool-Aid drinkers out there talk about lovely design patterns and clever ways to get around what to me is a very common requirement.

I did manage to bodge my way around it using a Callback a collection of ICommands and a ManualResetEvent. I even think it’s not that terrible a way of doing things although I’m probably wrong.


Is WPF all bad? No, certainly not. I think there’s a steep learning curve so reading a book before you start is a must in my opinion. However the clever databinding, MVVM and resource dictionaries make for a very testable way to program a UI. WPF takes away most of the rendering and re-painting that plagues me when I use winforms and is a blessing worth a fair amount of pain.

Is it right yet? I’m not sure but I’ll certainly play with it some more and see where my journey takes me.

I’d love to hear your experiences of WPF if you’ve tried it, and any solutions to some of my gripes above as I can’t believe I’m just not missing something fundamental.


  • Rate
    [Total: 65    Average: 2.3/5]
  • Nidrax

    “I liken it to using the experience using Word to edit HTML documents. Really you have no choice but to hand code it if you want anything even roughly resembling something maintainable xaml.”

    It’s not WPFs fault that your approach to layout coding is wrong. Using any WYSIWYG editor for making layout (and writing html) should be punished with a death penalty. Making WPF use structured html-like xaml layout is the best thing Microsoft could done to atone for their horrible aproach to layouting they used in WinForms.

  • Joe Smith

    WPF is a miserable experience for someone used to a more structured type of programming like c# winforms. Actually I see more and more of these “decorator” XAML type tags making their way into so many things. It just seems like a cheap solution by Microsoft to get around issues.

  • Anthony Mason

    I’ve literally never encountered these issues that you are describing, and I started off by reading that exact book. There was a learning curve, but there are certainly tools to do the job for you; you just have to know what you are doing. Have you ever used Blend in combination with Visual Studio? My guess is no.

  • EfUPrix

    It’s almost the end of 2016, and I still wholeheartedly agree. WPF can get quite painful to work with. The XAML designer breaks very often (VS2015), and errors in the designer itself is hard to debug.

    Blend is great for vector drawing, and an improvement over the default XAML designer. But the amount of stuff it spits out at you is mind-boggling (Try edit the template for a combo box). Plus, you’ll be spending most of your time looking for a context menu, or filtering the properties pane for something. I find it easier to just write XAML directly, and only use Blend when I need to draw some vector paths.

    With WPF, you almost HAVE to use MVVM, due to how verbose XAML is. The moment you mix a tiny bit of logic in XAML/code-behind, you’re in for a treat come refactoring time. It’s less painful to have the proper view/view-model separation up-front.

    Speaking of XAML, it’s like CSS’ retarded little brother. Merging styles is non-existent, except BasedOn, and even that only allows a single, StaticResource parent, unless you start writing extensions or attached properties. And getting simple things done, like binding the visibility to a boolean property requires the use of ValueConverters (BooleanToVisibilityConverter) or Triggers. I don’t know which is worst when it comes to maintenance: writing data triggers in xaml or custom value converters. Sometimes, it’s easier to just have a Visibility property in the View Model. And to top things off: some XAML attributes (ie, x:Key, TargetType) are order-sensitive!

    And did I mention how painful the XAML designer is? design-time data context often breaks/gets out-of-sync, styles are suddenly not applied (fully/partially) mid-way typing, and the only way to refresh is to either rebuild the project, or kill the xdescproc task and reload the designer again. On top of all that, as-of VS2015 Update 3, the XAML designer tends to freeze VS. Sometimes, switching between source files/xaml could take several seconds on a complex project! There could be a memory leak in there somewhere, but this has been around since VS2010 despite multiple Microsoft Connect submissions.

  • dbnex B

    Could not agree more. It is a half finished product or better to say salad bowl. It is a step in right direction done in a wrong way. And poor documentation and examples are contributing a lot to it. Very painful technology and seriously, VS IDE is most of the time hanging and doing some pulling, designer breaking all the time, very little help out-there although bunch of people claim they explain it very well. And MVVM is not very straight forward pattern either once you start using it. MS documentation sucks and is contributing to all this a lot.