Windows Presentation Foundation is Half-Baked

by dhovel 11. August 2013 23:29

Having written a fairly major WPF app, I think I can now write about it with some understanding.  While a well-crafted WPF app can be changed in amazing ways without much trouble, I think Microsoft has made some serious errors.  WPF remains a challenging platform, and one that may well not be worth the trouble.

The most spectacular aspect of WPF is data binding.  When apps can be designed from a completely data-centric viewpoint, WPF is a viable platform choice.  I shudder to think about “real” apps such as Vegas Video being written in WPF.  Data is important, but WPF is so inextricably bound to its data that flexibility is often left behind.

Some really ridiculous problems haunt WPF.  Why can’t resources be forward referenced?  This causes all manner of confusion (StaticResource vs. DynamicResource?) and reminds me of the early days of ‘C’ when I wrote all my programs backwards to get reasonable type-checking.

Resource problems plague WPF development.  Trivial changes to XAML result in crashes with absolutely no diagnostic information.  I’ve used dozens of code generators over the years and I’ve never seen a worse one.  Why can’t at least some file/line information be available for resource exceptions?  I find myself keeping “instant backups” for those times when the world ends without a clue.

Data binding is a mysterious as it is powerful.  Much of what I know I’ve gleaned by trial and error—put it in a {Binding} and see what happens.  AFIK, binding seems to rely entirely on run-time reflection: every name and qualifier (“X.Y”) is tediously parsed and resolved through indirect method invocation.  Why can’t WPF allow “static” as well as “dynamic” bindings?  That is, a “static” binding would be resolvable at compile time.  The primary DataContext for a UserControl or Window could be optionally declared in the XAML so that bindings marked “static” were resolvable at compile time; declaring a binding “dynamic” would explicitly bypass compile-time analysis.

Being a C# programmer from way back, I just don’t think that XAML will be truly useful until “lambda” expressions are allowed in XAML.   Why can’t “real” code be used without programmatically constructing bindings?  Just repeat after me: “It’s a code generator.”

How about all-important “property” notifications?  Well, there are two independent systems: INotifyPropertyChanged and DependencyObject.  Both require extensive coding and are highly error prone due to the use of “magic” strings.  The web abounds with “helper” classes to avoid some of the ugliness, but full AOP would be a blessing.  The model is simple: decorate a property with an attribute and bingo: the “set” accessor is only invoked when an actual data backing field change is about to occur, and the associated property changed event is invoked automatically.  There are commercial products that do this, largely through IML “weaving”, but they are costly, non-Microsoft solutions.  IMHO, the entire notification framework of WPF is wrong-headed.

And how about the vaunted “modifiability” of WPF controls?  Yes, you can put GroupBoxes around your ListBox items, but you’ll spend hours getting things right.  Why hasn’t Microsoft made it easier to see the “PART” inventory of complex UI objects and provide a slew of nicely themed controls?  The best example is this:  the code required to create a significantly distinct main window in daunting: hundreds of lines of XAML and C# just to override or alter elements.  And when your meticulously crafted XAML doesn’t work, will you know why?  No.

And don’t bother trying to use Expressions, since it fails to load all but the simplest VS WPF solution.  I’m really unclear why as to that product was introduced at all.

Nearly last but not nearly least, VS and WPF are both serious memory and processor hogs.  The layering of reflection-based late-binding on top of a managed framework creaks and groans incessantly.  Just because there’s Moore’s Law doesn’t mean Microsoft should assume that every serious developer has an octo-core machine with 16GB of RAM.

Finally, the acid test of the WPF approach is this:  How easy is it to support “skinning” and themes in WPF?  Answer: really, really, exceedingly hard.  This statement should speak for itself.