Six years of WPF; what's changed?

Published on: 2 Aug 2012

Prior to working full time on Octopus Deploy, I spent a year building a risk system using WPF, for traders at an investment bank. Before that I worked as a consultant and trainer, mostly with a focus on WPF. I've lived and breathed the technology for the last six years, and in this post I'm going to share some thoughts about the past and future of WPF and the XAML-ites.

Six years ago, I wrote an article about validation in WPF on Code Project. I also wrote a custom error provider that supported IDataErrorInfo, since, would you believe, WPF in version 3.0 didn't support IDataErrorInfo. Later, I worked on a bunch of open source projects around WPF like Bindable LINQ (the original Reactive Programming for WPF, back before Rx was invented) and Magellan (ASP.NET-style MVC for WPF). I was even in the MVVM-hyping, Code Project-link sharing club known as the WPF Disciples for a while.

As I look back at WPF, I see a technology that had some good fundamentals, but has been really let down by poor implementation and, more importantly, by a lack of investment. I'm glad those days are behind me.

Back in 2006, here's what the markup for a pretty basic Window looked like (taken from an app I worked on in 2006):

I originally became a WPF developer because I didn't like ASP.NET Web Forms and models like View State. But now, when I look back at the journey ASP.NET has taken, it has made huge changes. From the Web Forms model to the MVC model, from ASPX syntax to Razor, there's been some real innovation in the ASP.NET camp in that time. There have been some real innovators in the ASP.NET camp in that time.

Here's a list of things ASP.NET has done in six years that WPF hasn't:

Created a new, human-friendly markup language (Razor). Razor makes writing markup fun. XAML has never been fun. In fact before ReSharper introduced the 'Import namespace' support for XAML, it was downright torture.

Embraced design patterns. You can't claim MVVM here for WPF - WPF supports data binding, but the core of WPF doesn't actually contain a single feature that helps with MVVM; it's all layered on top through Blend Behaviors and third party frameworks. ASP.NET has an entire stack built on top of MVC.

Embraced the pit of success. You can actually build a maintainable application using ASP.NET MVC using the default project template. In contrast, without third party frameworks, the default WPF project template is the path to misery.

Embraced extensibility. Nearly everything in ASP.NET MVC has an interface or abstract class that you can extend to change how the framework works. There's a beautiful pipeline that you can plug into. I'd swear the WPF team never even heard of an interface, and the only abstract classes have internal constructors.

Embraced open source. ASP.NET MVC bundles jQuery and JSON.NET, and it's designed to work with a ton of open source tools. WPF, despite the litany of MVVM frameworks, and despite it being impossible to develop maintainable WPF applications without one, still hasn't embraced any of them.

Become open source. ASP.NET MVC was open source since early on, but now the entire ASP.NET stack is open source, and accepts contributions. WPF isn't, and frankly, you wouldn't want to look at the WPF code anyway; it's hideous.

On top of all of this, you've got the innovation that's happening on the web stack itself. Don't like CSS? Try Less or SaaS. Don't like JavaScript? Try CoffeeScript or Dart. There's a rich ecosystem of innovation happening in the web space at the moment, innovation that has never been present in WPF since 2006.

Apples and oranges and all that

I'm not contrasting ASP.NET and WPF in an attempt to say ASP.NET is better, that would be ridiculous, since they clearly serve very different purpose. I'm simply trying to show how one has come so far in six years, while the other has barely changed at all. I think it's all down to a lack of investment.

What's disappointing is that WPF started out quite positively during its time. Concepts like dependency properties, styles, templates, and the focus on data binding felt quite revolutionary when Avalon was announced.

Sadly, these good ideas, when put into practice, didn't have great implementations. Dependency properties are terribly verbose, and could have done with some decent language support. Styles and templates were also verbose, and far more limited than CSS (when WPF shipped I imagined there would be a thousand websites offering high quality WPF themes, just like there are for HTML themes; but there aren't, because it is hard).

Data binding in WPF generally Just Works, except when it doesn't. Implementing INotifyPropertyChanged still takes way too much code. Data context is a great concept, except it totally breaks when dealing with items like ContextMenus. ICommand was built to serve two masters; the WPF team who favored routed commands, and the Blend team who favored the command pattern, and ended up being a bad implementation for both.

XAML

And then there's the failure that is XAML. XAML is so verbose it's hard to imagine that humans were ever supposed to write it. And that's because they weren't! In the land of lollipops and rainbows, designers were supposed to use Blend and developers were going to use the VS designer, and no one would even look at XAML. Yet, it's 2012, and even as Blend has improved most people are still hand-writing XAML. This will not change in VS 2012.

The biggest failing in XAML wasn't that the tooling was bad though; it's that the language was never modified to cope with bad tooling. And unlike HTML, XAML isn't semantic. It's not interpreted. It is compiled, a serialization format, so there's no real separation of the markup and the implementation.

Here's half a dozen things off the top of my head that could be done to improve the XAML experience:

Allow XML namespace imports to be declared at a project level rather than redeclared in every single file

Allow binding events directly to methods instead of via commands

Make the binding syntax shorter and more easily memorable

Allow C# expressions like basic boolean logic instead of requiring converters all the time

Allow a boolean to be implicitly converted to the tri-state (dual-state in Silverlight) Visibility enum without a converter.

Stop making me use XML prefixes for my own custom controls

The ASP.NET team were able to create an entirely new parser (Razor) for their platform; why can't even minor changes be made in WPF?

MVVM

I can't begin to tell you how tired I am of hearing about this pattern, especially from ex-WinForms developers who think it is the bees knees because they read Silverlight Unleashed and were amazed by MVVM Light.

The reality is that every WPF project I've been brought on to has involved some guy thinking he was smart enough to invent his own MVVM framework, only for it to be a half-baked knock-off of someone's Code Project article. All WPF projects end up with a ViewModelBase that is so choc full of inherited members for threading and progress bars and INotifyPropertyChanged. Showing a view in a dialog takes 20 times more code than it would if you just put the code in Button1_Click, and it's equally as well tested since most people using MVVM are doing it because they claim it is testable but no one is actually writing unit tests for their view models, except the architects inventing the MVVM frameworks in the first place.

There's plenty of hype about MVVM out there, but the lack of platform support for it mean that every WPF developer will need to build a few bad, hard-to-maintain WPF applications before they figure out how to do it properly. That's a real shame.

Conclusion

Ultimately, as I look back over six years of working with WPF, I feel that it was a bunch of good ideas, that weren't very well implemented. You could say the same for the first versions of ASP.NET too (anyone remember Web Parts in ASP.NET 2.0?).

Only there's a big difference: ASP.NET evolved. The web stack evolved. Not only did the code change; the philosophies of the team changed. WPF on the other hand hasn't had a major change since 2006.

What's really sad is that there really isn't an alternative. In the web world, ASP.NET competes with Ruby and PHP; if I don't like one I can switch. On the Windows desktop, I'm pretty much stuck with WPF. And if WPF isn't evolving, that's a real shame.

You might enjoy working with WPF. You might think XAML is a beautiful, terse, fun to write language. That's how I felt in 2006, and if the platform is still enjoyable for you, that's great. It's going to be around for a long time, since there's really no alternative yet. But for me, I'm glad my WPF days are behind me, and that my full time job now is now ASP.NET-focused.

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool for .NET applications.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

mika

03 Aug 2012

I'm inclined to agree in general. Particularly the remarks about the lack of evolution. After 4 years I have concluded that WPF is a chore.

However there is one silver lining from my point of view. The very thing we criticize, the complex / verbose / obtuse nature of wpf, is what gives me an edge in the market. I do contracting work, and WPF contracts consistently pay 30% more than equivalent ASP.NET / MVC contracts. And it seems there are still a quite a lot of enterprises that want user interfaces that can't be easily delivered by browsers.

There are a million graduate monkeys being churned out every year that have the skills to get up to speed quickly in web frameworks. Windows programming isn't hip, and WPF is hard to learn, the demand is still there, and I go to work to make money. I play with ruby / mvc / python when I am not being paid.

My issue is that as the Technical Architect for an ISV that develops a desktop application for mass distribution; an application that for many strong reasons can't necessarily be delivered as a web application, and really doesn't suit the new fangled "Metro" approach, what should I be looking at to develop the next generation of our software?

Microsoft has placed WPF, Silverlight and WinForms firmly in the Legacy technology stack, and with very little love being shown to any of these (at least none visible to me), I am left wondering if MS even have a strategy for these types of applications. On the same token, as you said, there is very little choice, and at the moment, I would be forced to choose WPF with all of its issues.

I think you have two issues here, interlinked. The first is the state of WPF after six years - with hardly any language support for Dependency Properties or INotifyPropertyChanged. Here, I agree with you entirely, both in the initial promise of the platform and in the disappointment that it wasn't followed through. And at this point, I don't see Microsoft overhauling WPF and giving it a second shot. It's sad, but it's done.

The second issue is XAML as a markup language. With WinRT coming up and Microsoft doing its darndest to push Metro apps, this is a chance to give XAML a makeover. I don't dislike the verbose XAML syntax as much as you do, though I certainly found myself nodding in agreement over many of your points. But this is a turning point. As a markup language for a non-prioritized desktop platform (WPF) or an also-ran Flash competitor (Silverlight), XAML was never given enough focus. Now that the XAML team is part of the main Windows development group, it finally has a chance to see improvement as a first-class language.

mika: Paul's sample code is good criticism because of the Pit of Success that he mentioned. This is the default code that's generated by Visual Studio, so that's the code you'll see for 90% of WPF windows out there. Claiming that XAML isn't that verbose since you can strip it down, is like saying C++ isn't prone to memory leaks and buffer overruns just because you can code safely in it. You can, but it's not the default behavior.

I agree, and I'm in a similar boat. The installation tool for Octopus Deploy was written in Windows Forms, but I needed to make it look better for the 1.0 release, so I updated it to use WPF. I didn't enjoy working on it (compared to Razor) but there wasn't much of an option.

@mika,

It is redundant to set height and width, as well as WindowState="Maximized" :-)

Not exactly - if you un-maximise the window, it will be restored to the specified Width/Height. Without that setting the default window size after restoring might not be ideal.

You have included tb and tbp, which must be useful UI elements, otherwise your woudn't include them, but there is no equivalent of whatever they represent in the razor version.

The vast majority of XAML files to have imports, so I think it is realistic (and that code is actually pasted from real code I wrote in 2006). There is an equivalent in Razor, via the @import directive. However, in Razor, you can also specify imports in the web.config file, which means you don't have to duplicate them in all of your files (unlike XAML which loves duplication).

@Chris Nahr,

I think you are right that the lack of competition is the reason for there not being much investment. That said, Microsoft seem to have a lot of trouble getting momentum on their app stores compared to iOS devices. Maybe if they made the platform more fun to work with, they would get more apps?

@Avner,

Good observation that XAML is now a real part of the Windows team. Time will tell whether that will mean extra investment or innovation. Historically I don't think the Windows team have ever been terribly fond of XAML.

andy

03 Aug 2012

+1 for Mika, that's a much better comparison.

Overall though I do agree. What frustrates me most is that no-one from MS ever seems to come out in support of WPF, seemingly the majority of WinRT examples and samples have been written in HTML/JS (I'm sure the mail app is). As usual there is no comment from anyone at MS about the general roadmap or acknowledgement that most developers aren't going to develop for Win8/Metro for a long while yet. The conclusion must be that they have dumped WPF in favour of HTML/JS in order to be more web-friendly, we just now need to see the ability to create desktop apps on WinRT.

What frustrates me most is that WinRT is going to be out there and it's probably going to be marketed as the WPF replacement, but it's going to be limited to a few select platforms (Win8 and up?). This effectively means you're unable to use it as the main GUI layer for any application you're building for the next 5 or so years.

Basically the same thing you have when doing web applications and you need to support IE8 and below.

In the situations where I need to support as many platforms as possible, I have in the past simply reverted back to using a library like Qt. It's C++ but especially in combination with Qt Creator I can ensure it'll work on people's machines without any hassle.

Couldn't agree more with your view on mvvm. I started on WPF recently so it's interesting to read that little has changed over the years.

Maxim

03 Aug 2012

How long will it take you to get bored with html, razor, javascript, jquery, knockout, asp.net mvc, css, browsers incompatibility?

Looks like you didn't do serious web related job. At least long lasting enough.

Brent

03 Aug 2012

I didn't have to adopt WPF because I didn't like the first release of it and thought it had a rocky future. In retrospect, I was mostly right and glad I never got on board.

Like others have said, Microsoft is only hurting their ecosystem by not giving developers a good toolkit/platform/framework to make Windows apps. I don't want to think too hard or too creatively to create a good Windows app. There are too many apps that simply run on Windows.

Bob

03 Aug 2012

Also there is another issue with big WPF projects and it's the poor performance. Probably that's why MS has invented native C++ XAML style apps for Windows 8.

Steve Solomon

03 Aug 2012

Paul. Great post mate. Could not agree with you more, and I know a number of the WPF disciples do too. Rich G and I and doing a lot of MVC work at the moment, and we are loving it. Be interested to hear what Mr. Barber has to say on the subject!

BillyJack

03 Aug 2012

I don't think you are reading your article. You complain that the tools, designer are not good but you say you do not use them and that you are hand writing xaml. If you were using the designer then you would not have problems. It will put in the namespaces for the controls that you add to your view. It is way easier to work with a designer and you are visualizing the UI right away verse writing out a bunch of xaml and then navigating to a designer to see what you designed or building the code to see what you designed.

In your half a dozen list step three you complain about how hard it is to remember the xaml syntax. But if you are hand writing xaml like you say you are then you should not have a hard time remembering the syntax.

You complain that there is not enough support, frameworks, patterns but you complain about the ones that do exist and it appears you do not use them.

BillyJack

03 Aug 2012

I do agree with some of the problems that you mentioned and it is your opinion if you hate xaml. I just don't think that you developing xaml the right way and utilizing what is available. There is designers for HTML and CSS too but you can keep writing pages by hand if you like. We can even write code in a text editor if we want but without a good IDE it is painful. If you do not use Blend for xaml and you do not know how to write xaml or anything about it, then yes it is painful. I think if you have been developing WPF for six years then you would know how to use the tools, frameworks, and patterns and would be well passed the few problems that there actually are.

Every technology have problems. We learn what they are and how to deal with the. It does not matter which technology you read about. There is always people who love it and hate it. As a developer we have a choice of which to pick and use and where to work. So pick what makes you happy. Pick your choice of technology, framework, tools, patterns and be happy. No matter what, you will always have to keep learning and yet remember what you have learned.

I've memorized that syntax over 6 years. But I've also seen people's eyes glaze over when demonstrating it as a WPF trainer. You might believe that the syntax above is the absolute pinnacle of human achievement in language design, but personally I think it could do with some improvement. Yet with 6 years of XAML, there has been none.

Every technology have problems. We learn what they are and how to deal with the. It does not matter which technology you read about

Very true. The difference is - and it's the point of this post - other technologies are evolving, while WPF hasn't. People who hate JavaScript can use CoffeeScript. People who hate CSS can use SASS. People who hate the XHTML syntax can switch to HTML5. People who hate XAML can use... what?

While I agree with you, it's a bit unfair to compare the (lack-of) change in WPF markup over the years to the difference between WebForms and MVC. WebForms markup is still just as ugly as it's always been!

Andre

04 Aug 2012

@Paul Stovell

I've memorized that syntax over 6 years.

I never used that syntax directly, but rather used Blend to let it handle all the basic stuff for me. Who really want's to use and edit that syntax in XAML directly?

While I'm not an WPF expert, I still think it's superior compared to WinForms and all Immediate Rendering Frameworks.

Just such simple tasks, like defining global resources for margins and use them in the application or databinding with design preview is not that simple with WinForms as it's in WPF.

I cannot speak for WebForms, but I think WPF is not that bad if you don't touch XAML directly.

ct

04 Aug 2012

I totally agree about XAML's verboseness and want something like JSON style coding -- maybe someone someone can write a pre-processor like LESS/SASS to allow using of curly braces/colons transforming to brackets/equal signs/double quotes.

Also having multiple inheritance for styles with overriding like CSS would be so much more helpful.

Never thought before about the default projects out of the box support for a framework like ASP.NET MVC, but totally agree that support for a MVVM framework out of the box when selecting a New Project would be a step forward.

I'm still holding out on ASP.NET as I feel everyone's doing that, and the best way to differentiate myself from the hoards of web devs is to do desktop development as there's still privacy/data concerns with web dev. And if I were to jump ship from WPF it would be like Josh Smith to go over to Objective-C and do Mac/IPhone dev of which I've bought his book and is a great help in transitioning over from WPF to iPhone dev.

Dan M

04 Aug 2012

I definitely agree that Microsoft has done little to advance WPF over the years, especially when compared with ASP.NET. XAML definitely doesn't measure up to Razor (although Blend does eliminate some of the need to read and manipulate XAML by hand). INotifyPropertyChanged is a nightmare (although there is at least one good workaround). The lack of strongly typed views is a definite blow to productivity and refactoring. However, my experience has been that web development is just plain harder than desktop development, even with a great framework like ASP.NET MVC:

First, if you are making a Window's app, it will usually just work on any Windows machine. Most WPF apps I've written work fine on XP up to 7. With web development, you have to worry about your app looking and working properly on a huge spectrum of browsers and devices.

Second, to build a WPF app, you basically need to know XAML and C#/VB. To build an ASP.NET/MVC app, you need to know aspx/Razor, C#/VB, javascript/CoffeeScript/Dart, and CSS/SaaS. You also need to understand IIS, know something about servers, and understand how to secure your app from hackers (a huge topic). Also, despite needing a third-party library for MVVM, my WPF apps have required far fewer external libraries than my ASP.NET MVC apps.

Absolutely, this is an unfair and maybe even ridiculous comparison (and my assertions are based on my experience as a mostly solo developer supporting R&D). Certainly, the ability to build an app that can be used anywhere by tons of users simultaneously and updated almost continuously should be a much bigger undertaking than building something that runs only on Windows machines and often in isolation. My only point is that developing a WPF app can be quite pleasant and productive, despite WPF's many flaws, while writing an ASP.NET MVC app can be quite painful and tedious, despite MVC's many virtues.

Jared Roughan

05 Aug 2012

Couldn't agree more. It's been a few years now since I've written anything non-trivial in WPF and I don't miss it. It's one of those technologies that could've been great if it had been given any attention but it wasn't and it isn't. I'd still crack open WPF over WinForms for any small helper app that could use a GUI but that's purely for the binding support. At least memorising all that syntax didn't go entirely to waste!

Like you I've been involved in ASP.NET MVC development since then and with the wealth of investment in frameworks by MS and OSS communities it makes small apps fun again and large apps structured the way they should be (not to mention client side binding support).

It'll be interesting to see what happens to XAML in the WinRT world with other languages coming on board, but I wouldn't recommend new developers spend time wrestling with it as the focus is clearly on web technologies.

While I don't work in WPF, having only created one or two apps, I do work in ASP.NET MVC, and I have followed the technical blogs about WPF as well. I have to agree with Paul concerning the issues outlined above, even though there are those that claim that using a Designer will alleviate some of the issues.

Thing is, we don't want to be reliant on a Designer; we want to be able to look at the code, XAML or ASP.NET or Razor, and be capable of understanding what we are seeing.

For example, with Razor, the whole premise was that it is much easier to write the actual code, with fewer characters to type and greater readability. Having worked with ASP.NET WebForms and MVC for a while now, I have hardly, if ever, seen someone using the Designer. This is partly because it couldn't always be relied upon, but mainly because we wanted better control on what was being written.

Memorizing syntax? Why? You should be able to read it and understand it, it should be intuitive. Also, why mix languages? If you are using XAML, which is an XML based language, why do you need to write bindings in something else, which incidentally doesn't even have very good support in the XAML editor?

Paul, good to hear someone verbalize what I've been feeling on this. The initial excitement around Avalon (WPF) was great - a promising technology that was going to really change the way Windows applications were developed. It has done that, but could have been better with more attention from MSFT.

I totally agree with most of this. However I like my viewmodelbase class. That said I too am loving razor knockout and Mvc and absolutely concur on its extensibility. I would love to see less converters and I have even tried to fix this using iron python to evaluate expressions. But yeah it is hassle.

But your point is received that Microsoft doesn't push the user in the right direction enough. And once again on metro we find ourselves in the same position (maybe worse off because MEF has been watered down).

I've recently started putting together a Metro application and out of it has sprung a Framework for Metro (http://stylemvvm.codeplex.com). As someone that is looking to share experience and a common code base.

What are the thing we can do to address them problems through 3rd party tools?
Obviously things like IOC Containers and Regions have to be supported. But It feels like something more needs to be done than just dropping down a VS Template and say have a good day.

What can we need to add to the Metro platform to make it succeed because honestly I do like the XAML + MVVM stack.

Daniel Fernandes

06 Aug 2012

An excellent post indeed.
I agree with most of what you said.
How can one become so frustrated with XAML in particular knowing that this actually gets compiled therefore offering plenty of opportunity of compile-time optimization or simply better tooling to make it keyboard friendly.
Compare that to HTML/JS/CSS where it has to be interpreted at runtime.
If I had to guess from the present situation I would say Microsoft has spent over 10 times more in Web related client technologies compared to WPF in the last 3 years.

It's a shame indeed because WPF started off well but implementation and lack of budget let it down.

I think as well that this shows the complete failure of bundling client stacks with the core runtime which follows the cycle of OS releases.

Dear MS, you've got it completely wrong, the world doesn't require to webify everything. Give us a developer friendly, powerful and extensible enough GUI toolkit alongside some good, non-intrusive tooling and it will sell and you will stop losing those talented developers.

Although the crux of this article is right that WPF has not evolved as much as it might have, in my opinion comparing it's evolution with ASP.Net is not fair.

I am working on developing enterprise applications using WPF from last 4 years and despite lack of improvements I think WPF is a great platform and developing desktop applications using WPF is not as bad as pictured here.

The binding syntax you mentioned is tough to understand at first but not if you are working in WPF regularly and how many times you need to do that (finding a parent by type, using it's DataContext, use converter and StringFormat together) specially if you use MVVM, rarely I would say.

I am not saying improvements you mentioned are not good but are not blockers and doesn't make WPF a bad platform. Improvements are definitely required and I hope they will happen with time but even without them WPF is a great platform to develop enterprise desktop applications.

Allow XML namespace imports to be declared at a project level rather than redeclared in every single file.

-- nice to have but I am not bothered with that, it's generated automatically and Resharper tells me the ones not used and can be removed.

Allow binding events directly to methods instead of via commands

-- Yes that will be nice but if I remember correctly various MVVM frameworks have implemented ways to do that.

Make the binding syntax shorter and more easily memorable

-- If you design your Data correctly and set DataContext's properly, 90% of the time syntax is very short just having the property name. Only in case of very complex UI you need ElementName, RelativeSource bindings(which I don't think is very tough to understand, for experienced WPF devs.)

Allow C# expressions like basic boolean logic instead of requiring converters all the time Allow a boolean to be implicitly converted to the tri-state (dual-state in Silverlight) Visibility enum without a converter.

-- That will be nice to have but it's not necessary to use Converters, triggers suits these kind of tasks perfectly and are easy to understand.

Stop making me use XML prefixes for my custom controls

-- That's more of a personal choice; for me it's nice to distinguish the custom controls from the inbuilt controls; I can create different prefixes for various libs. in my project and distinguish between them without going into implementation to check that.

BillyJack

06 Aug 2012

I do admit the syntax can be confusing and hard to remember. I also agree WPF has not got enough attention and it seems WPF now has no future. XAML lives on with WinRT.

@Schmulik Raskin I am not saying that someone should rely on a designer. But with WPF the designer works great. There are problems but once you use the designer for a while you gain experience with the xaml. Then when you need to go into the code and tweak the xaml or even write xaml it is way easier. Learning xaml before the designer is difficult. When writing ASP.Net, HTML or CSS I also hand write all the code.

That is what is nice about WPF. Using the designer you can design your UI and wire up the UI to test data for design time and to real data for run time. I remember when I started having to learn Expression Blend and I complained. I made it a habit to never look at the XAML and to always use the designer. It took very little time to learn. When I trained other developers they complained and kept wanting to just give up and hand write XAML. However, that is hard specially when you do not know the syntax and took them longer to learn. With XAML, you just need to learn how to use the designer. Then development is easy.

By the way, I use GalaSoft MVVM Light Toolkit which installs templates for MVVM projects and pages. If you add a new view it will also add a view model.

I never understood why they didn't simplify the binding. I ended up creating my own binding that allowed me to bind without the complexity, especially when binding buttons to method.

I ended up with bindings that look like these examples {BindTo FirstName}, {BindTo Person.FirstName}, {BindTo SaveObject()}. To reference other WPF element I used the CSS selector syntax {BindTo #MyTextBox.Text}.

There are also simple syntax's for binding to ancestors, templates, etc. I created this library because WPF seemed way too verbose, and I kept waiting for them or someone to simplify it and it just never happened.

Is it that WPF doesn't have a large community like other technologies? Is it still salvageable? Is it just a matter of a couple of tweaks? Of is it too late?

In any case, if you are interested in the library I mentioned you can find it here: http://www.simplygoodcode.com/2012/08/simpler-wpf-binding.html

WPF on its own is more career-limiting than MVC on its own; there are no "pure ASP.NET MVC" developers, because front-end knowledge is essential to working with MVC.

Frank

07 Aug 2012

Interesting post...

I've suspected that what one reason that WPF has got no love is internal Microsoft politics. Specifically the Windows division not liking it, maybe b/c there was no C++ implementation and, I suspect, the majority of Windows devs are hard core C++. And of course not being fans of its brother Silverlight (I've read that it was refer to internal at times as the 'f.u. windows' sdk)

Giving no clear path forward on the Desktop and Microsoft pushing html\js in the Metro space seems crazy to me. One theory is that a hordes of web dev's will write Metro apps. But just as likely is that all the existing Windows Desktop dev's will start writing web apps, and that does not necessarily mean ASP.net pages. And it might mean specifically NOT Asp.net page since they will be feeling slighted ... "Fool me once, shame on you; fool me twice, shame on me"

I have to admit to agreeing with the bulk of this. I fall very much into the camp of a 'write your own MVVM framework' developer, and I'm STILL having to change it almost daily as I work on WPF projects. However, it is worth pointing out that I think the reason that this is SO frustrating, is that actually, there are some things about WPF that a really good - fast UIs, animation, DataTemplates, there are certainly some things about WPF that can feel very graceful at times.

But there is a distinct lack of evolution of the platform. This is particularly distressing because MS pushed it so much, we've invested in training, built products with it, and MS seem to really not be bothering to improve up on it.

Bassam

07 Aug 2012

Dont agree that there is no alternative , I use Windows forms with DevExpress controls producing great forms and applications , users are very happy with, very powerful controls with Designers that makes life easier , no need to stair at XAML at all, it works !

onur

07 Aug 2012

I am so surprised to the post and also to the comments.

He is comparing ASP.NET WebForms to ASP.NET MVC and tell this as an evolution despite the fact Microsoft emphesized ten thousand times that MVC is not a replacement to web forms. They are apples and oranges.

For xaml and WPF. I've seen so many improvements over .net 4 and .net 4.5

What's new in WPF 4:

http://msdn.microsoft.com/en-us/library/bb613588.aspx

What's new in WPF 4.5
http://msdn.microsoft.com/en-us/library/bb613588%28v=vs.110%29.aspx

I came to the conclusion 6 years ago that WPF was a dead end. Winforms is/was a solid and reliable platform to build apps on and its EOL is a big mistake because it does address the need for light fast apps...

however on the point of alternatives and innovations, in 2010 it was clear to me that a desktop experience based on a webstack like OS was the true way forward, and it was already apparent to me that xml declared UI was wasteful and indirect in many ways. (based on experience with XUL and GTK/Glade) [indirect being the main problem]

I came to this conclusion having developed my own xml engine to render winforms on the fly, then I realized that Mozilla XUL was doing the same thing with there own UI... step on a bit and remember the ie functionality when you rename an html file to hta to make a web page work like an application. It was around that time when I saw a future that just needed a desktop which was in effect an html canvas, add in a widget concept that you can draw to and script on the fly (Lets assume it would be intuitively called canvas and replace the need for activex/appletes/extensions) and a trusted servlet style container where you can install packages.

What you get then is a very flexible UI, a natural 2/3 tier stack with true separation of concern, a fully developer controlled UI, and light net traffic because all commands are passing via the middle tier (controller) installed in he container.

... Now if this is starting to sound familiar good... WPF is a dead end and asp.net/winRT is moving closer to the kernel whether you like it or not.

David Roh

07 Aug 2012

Okay, great - so now what?

The biggest issue that I have with WPF/Silverlight is performance.

The unanswered question is what is the best technology path forward?

I really like Silverlight and SL5 has awesome 3D capability and will run on more platforms with out any change than any thing else that I know of (please correct me).

Develop for WinRT - maybe, if there is really good market penetration; however, I don't want to develop for only one platform - will WinRT stuff run on Windows 7, if not, then why would I develop for a single, niche market with no current market penetration?

For the last six months I have been working very hard to come up to speed with Mac and iOS development and while I am not fond of Objective-C syntax, it is certainly usable and performs well (I now even have a MacBook Pro Retina for development).

So, were do we go from here - HTML 5 may be okay but writing large LOB apps in JavaScript, for me, is a non-starter.

I can't begin to tell you how tired I am of hearing about this pattern, especially from ex-WinForms developers who think it is the bees knees because they read Silverlight Unleashed and were amazed by MVVM Light.

That was funny. I was doing exactly that for winforms (JV.MVVM for WinForms) when I realized that I was going down the same path you are decribing... so I stopped.

And yet, MVVM provide the value of making the UI pluggable, which is very attractive.

Merennulli

07 Aug 2012

I was very excited about WPF at first, but the more I delved into it, the more I felt it was just like a very immature ASP.Net - Nothing was built for it, nothing worked particularly well. The only benefit was a slightly better GUI appearance, while functionality took a nosedive in the name of technological purity.

Like anything new, not having years of buildup gives the misconception of cleanliness and purity that draws in a lot of developers, wanting to believe the old problem of bloated languages is addressed (if not solved). And then they need things that aren't there and demand the language be bloated.

WPF still doesn't have the necessary bloat that WinForms have. It's a slow way to create an interface, despite claims to the contrary. It falls into the "start with a blinking cursor" trap, and lacks any real GUI shortcuts or even the matured intellisense of WinForms.

I had hoped WPF would mature and displace WinForms, but it looks like it will never get there now.

I agree with you about the disappointing lack of support; WPF is/was a fantastic technology, but it seems the learning curve was too steep for the average developer and Microsoft walked away from it. I thought moving Visual Studio to WPF was a great move and would help more than it did.

My biggest complaints about WPF (after lack of MS love) is weak data typing - trying to maintain a XAML page/control/template and figuring out exactly what the heck the data context is. Usually I find myself sticking in labels that just print out the current data context's type so I can start to figure things out.

And yes, writing code in XML is never really fun, and as a small business I don't have a dedicated designer using Blend. So a Razor like WPF syntax would be fantastic (that is, something custom and highly productive). I also completely agree that more extensibility would be great.

For INotifyPropertyChanged I use AOP with PostSharp, which makes it completely painless (but it's one more technology to buy, know and add to your build server (although that's very easy)).

And you're right: I don't unit test my view-models half as much as I would like to, but I do unit test the complex bits.

Finally, in my investigation into iOS programming I was shocked to find the state of Mac programming SO far behind WPF (which as you point out is 6 years old). There doesn't seem to be any concept of type templates, and no data binding?! Unbelievable. I'm always shocked when a Mac developer seems pleased with all the code that they write, when I could do the same with WPF (WPF!) in a fraction of the code and with better view/model separation.

Thanks for the article.

Robert

Matt McGuire

07 Aug 2012

I too looked forward to WPF at first, but with no tooling support, I left it on the shelf and continued working with the stable winforms (industrial control can't have a flighty nature). although WCF Rocks!
With every new release of VS I would look at WPF again always dissatisified with the tooling and documintation to get started with WPF. Deadlines always loom and being the only developer / designer I was not going to stake a new product on something that felt half@$$ed from MS.
Now windows RT is out for Win8 and WPF is already being shuffeled away, I feel I made the right decision to skip WPF, but does winRT give me any advantages over winforms currently?

*Run on older systems than 8? No.

*Better access to underlying OS? No. In fact less than before.

*Interop with other OSes? No. If I compile to Mono with a winform app I can.

*Increased low level access to hardware? No. In fact less than before.

So I'm still not seeing the driving push to move forward like I origionaly saw with moving from C++/VB to the winforms/dotnet framework.

Justin

08 Aug 2012

I built a custom ERP system with WPF for my previous employer and see many of your points. I found XAML fun except for the themes. C# expressions in the XAML would be perfect. But what I find annoying is all of the boilerplate code required for MVVM that should just be built in. Microsoft really pushed MVVM but it is more difficult to implement than just doing it in code-behind files.

I also agree with your point that MVVM doesn't help with unit testing at all. At least, not in my experience. A popular method of using ICommand that I learned was easy enough to use but required that the command be routed to a private method inside the ViewModel. The thing I never understood was the fact that if all of your methods are private, how can you possibly unit test them? I just unit tested the outside business logic classes that the ViewModel used and hoped that was enough coverage.

Andrew Boisen

08 Aug 2012

Your sections on XAML and MVVM rang true with me and I couldn't agree more. Having done WPF almost exclusively for the past four years for a variety of employers and projects, I have seen projects whither and die under the weight of CAB and PRISM (all for the sake of unit tests that never got written). The only project I did using WPF that turned out clean, elegant and simple was when we embraced the use of events, forms and controls.
Don't get me started on the XAML binding syntax either. The amount of times I've seen a WPF newbie gringe away from binding make me sad for what should have been.

You think WPF is bad, has anyone done a Java GUI recently? I don't think anything there has changed since the 90s.

Allen

08 Aug 2012

After 6 years of working with WPF, you should be adept enough at it to see that it is not as difficult as you claim. I completely agree that the technology was left behind some of the things that just worked for Silverlight. However, it had more advanced data binding routes than Silverlight. Writing and working with a video player control in WPF is abismal compared to Silverlight. It sounds like in this article that you never were able to "get it". I mean never able to quite find the right set of patterns and tools to make it fun for your work. MVVM is a useful pattern that allows better separation of concerns than the easy to hook up button click events you mention. I would like to take on some of your older WPF projects and fix them to work with this pattern. It would be a joy to do. There are other patterns and yes third party projects that make working with WPF easier. What I've seen though is people relying too much on those and bogging down their code. When developers say they like using PRISM, it makes me cringe to think what the code looks like and how painful it would be to maintain. So, you have a fair point there. But developing with ASP.Net using even the latest syntax and nifty routing techniques isn't free from third party gems. In real world scenarios, you are going to be using jQuery. Once that pandora's box is opened, you find yourself hunting for other JavaScript frameworks or CSS helpers (LESS) to glob on to your web project. It doesn't end there. The point is there are different and as many or more problems with ASP.Net development in a real world scenario. I have to agree with other commentors that comparing the two is like apples to oranges. I'm sorry to hear that you don't like XAML. Given my experience with ASP.Net (classic to modern), XAML is so much more consistent as a UI layout language that I have to say it is easier, for me, to work with. That said, to each his own.

Raphael Muindi

08 Aug 2012

I cannot believe anyone is actually complaining about WPF. If you were to create a customized window frame with an animated icon do you know how long you would take? Yeah, that's right forever. WPF is a great technology it is its consistency that make it easy to understand from .NET 3.5, .NET 4 and hopefully .NET 4.5.

Paul Harrington

09 Aug 2012

Great post Stovey!

Its such a shame a lot of these ideas are either badly or not fully implemented and it looks like the WPF code code set is not getting anymore investment.

Hopefully MS gets it act together and makes WPF code open source and then the community can take over fixing some of these bugs.

What would an alternative be to build a touch based vending terminal application where you want to design every control and all the behavior?
Is qt an alternative, since I can't find a framework that doesn't restrict you design wise.
In WPF I can open a adobe illustrator design an export it to XAML with Expression Design. Then split the element into controls and write the code behind. And with that I made an application that looks exactly as enwisioned by the initial designer.
Is that possible elsewhere for native apps?

Paul, very nice article! I am thinking about what you wrote ever since I read it and I was wondering if anyone would be interested to start an open source project to create something similar to the razor engine... Is this a good idea at all?

From what i gather, most of your points can be taken out with few conventions and a nice framework.
Haven't quite done anything with WPF, more into Silverlight, but i do know that for instance Caliburn.Micro is also available for WPF, and that it's convention based, and i mean conventions to extreme (data binding, VM-V connecting, composition etc). It's fantastic and i really don't write that much of ugly code, or code which feels redundant. It also supports binding to methods instead of using command pattern (haven't written one in ages). And it's definitely a game changer for XAML. I'm quite surprised no one mentioned it.

Hasan the dude

13 Aug 2012

great post, agree with most of your comments, keep it coming

krissi

13 Aug 2012

I've been developing in WPF for almost three years now and I agree with you especially MVVM -> more trouble than it's worth, and yes we don't write test for it anyway :/

brett

15 Aug 2012

I totally agree.

WPF is amazing when you start and it just gets steadily worse the more you work with it.
Eventually you start hating it.
It is just way too hard to do anything sensible in it.

MVVM is pretty much essential because it is pretty much impossible to unit test anything from the UI. But all the bugs in WPF are UI bugs so you land up in a catch 22.

There are parts of WPF that I still love but for production projects Yuck

I agree that Caliburn finally helped things but wow what a long time before it came out got stable and got enough documentation so that anyone could use it.

guys, grow up.. run where there money is. today there is money in wpf. do it. tomorrow there will be money in some other technology. that time run for it. after all in the world of IT, we are all bitches. we run where the fun is. And to me money is fun and i do WPF for the same reason.

Oh by the way.. there is a bit of money in ios as the moment. So i am also doing some ios too..

check out my company site : www.philino.com to have a glimpse of some of the apps i have done.

Although i agree that WPF didn't get the attention that Silverlight did, it still has some cards hidden in its sleeve, such as: supports for an extensive range of 3D features, support for all types of routed events, the possibility to access local file resources etc.

so, even if some of you are hurrying to declare WPF as obsolete, i would give up on it just yet.

some time ago i actually wrote a case study about wpf vs silverlight, so if you are interested, here it is:

As someone who jumped on the iOS bandwagon a year ago, this is just another "grass is greener" post.

The iOS apps I created to learn Objective-C and iOS were straight forward trivial consumer applications. It was wonderfully liberating and once AppCode, (from JetBrains), was released life became so much easier.

I then got a professional job at a company specializing in Mobile applications for iOS, Android and Mobile Web.

OH

MY

god

I have been working on the same application for over 6 months, the app was in production 6 months before I joined and what a nightmare.

Once you cross over into Enterprise application development, the wheels fall off. The ecosystem for iOS is so primitive compared to the MS Stack. InterfaceBuilder? What a joke, its more primitive then the UI designer we had for VB 3. (Again, thank goodness for AppCode.)

Well, my company wants to jump into Windows 8 tablet and WinPhone development and asked me to lead up the group. I have to say, I feel like I've come home. Missed C#, missed the frameworks, missed the tools, missed the rich and robust eco-system. (We have two high profile projects for Windows 8 and WinPhone 8.)

Though I also agree with Saraf Talukder, go where the money is. If the Win8/WinPhone initiative doesn't work out I'll be back on the iOS team. As an iOS developer I can make a lot more money.

Paul Mc

12 Sep 2012

Six years of WPF experience? I expected more sophisticated bitching.

Fritz Francis

25 Sep 2012

Paul,

No matter what anybody says about you (especially Paul MC), but you DA man!!