When WPF was first released I wrote a blog post stating that it would take a little time for it to take off. It has been over two years now and I’ve been proved more right than I expected. I think WPF has great potential and allows some amazing user interfaces to be created. But somehow it just hasn’t taken off.

I expected it to take time because any new platform needs a chance to mature and the associated tooling be created. Even so I expected that by now it would be getting into its stride and starting to overtake WinForms as the client technology of choice. I think there are two reasons why this has not happened.

WPF Tooling
So far this has not reached the level needed to make it easy for average developers to use. Sure, we have Expression Blend and the Visual Studio design time environment but neither is as simple to use as the WinForms design time surface. If you’re not a designer, and most coders never will be, then Blend is really not that easy to use. It’s easy to create bad designs with Blend but you’re going to need to be a skilled designer to make it really sing for you.

So unless your organization has the resources to employ a designer you’re stuck with using the standard out of the box look and feel. That standard appearance will not have your customers or boss into begging for WPF applications.

Now this would not be such as issue if there were some great component suites that you could buy and just drop into your application, along with a selection of great themes. The current component suites for WPF are getting better all the time but still at least 1 or 2 years away from providing the depth and range required.

WPF Applications
Our second roadblock to adoption is that we have no good examples of WPF applications in the wild. Yes there are plenty of cool niche apps but I mean really popular apps that are on everyone’s desktop. Something along the lines of Microsoft Word with a WPF front end. Something that gets the mass market asking for the same sophistication from all the applications they use. This would create a demand side pull on software companies.

Of course, the problem here is that you cannot take several million lines of code inside Office and just stick a WPF front end on. This reminds me of an interview I heard from a developer on the Outlook team. It took a team of three developers two years to create the Outlook 2007 navigation control that you see on the left hand side. So we cannot expect the consumer market to get anything from Microsoft in the immediate future that is going to really fire them up.

Supply Side Push
If a demand side pull is unlikely to bring WPF to the masses then the only alternative is for Microsoft to create a supply side push. I think this is the main reasoning behind the recent announcement that Visual Studio 2010 is to have a new text editor built using WPF. They also stated that Version 11 (Visual Studio 2012?) will have the entire shell rewritten in WPF.

Now you can imagine that a million Visual Studio developers will see the cool and slick WPF environment and decide they want to get in on the act. At this point WPF will be the default choice for developing rich client applications and by then the component vendors will also have some nice offerings.

So my new prediction for WPF uptake is a slow but steady increase over the next four years and a tipping point at around 2012 that sees it become the de facto standard for developing client applications. But if you think differently then let me know in the comments!

8 Responses to “WPF adoption”

  1. James Says:

    The problem is that their is no business need to move to WPF. If I convert my app to WPF then I gain zero sales and lose money that could have been earned by doing something else.

    In this economic climate, fiddling with unproven and unnecessary technology that provides no tangible benefits to customers is never going to happen.

  2. Duncan Smart Says:

    I think the .NET 3.x install process is a joke. It should take users a few minutes at most to get .NET client stuff installed, but (seemingly) because of Windows Installer, these things take an age (OK, 20 mins) with copious amounts of disk thrashing. If the install experience were more like Silverlight or Adobe AIR even, then we might be getting somewhere.

  3. Judah Says:

    James is wrong; there is a business need to move to WPF: less code to write. WinForms support for databinding, for example, is so basic it’s almost useless. We have to write tons of boilerplate code like:

    checkBoxClickHandler(..)
    {
    if(checkBox.Checked)
    {
    textBox.Text = “checked”;
    label1.Enabled = true;
    ….
    }
    }

    Ugly, boring stuff that is time consuming to produce and painful to maintain.

    WPF databinding takes care of all this. Less code to write, fewer bugs.

    Phil’s prediction is realistic: in a couple years, it will overtake WinForms.

    Which begs the question, Phil, are you planning on becoming a WPF component vendor in a few years, or stick it out with WinForms?

  4. vesuvius Says:

    I’m afraid Judah, it is you that is off the mark. WPF databinding is phenomenal, but it is also not without it’s drawbacks. Try create a menu and toolbar, with all the images and event handlers and you will soon find that you are writing boilerplate XAML where in winforms it takes 2 minutes.

    I will write an answer to this post in my blog and link to it later (longish article not self promotion – oh well, I care about this subject).

    I would also recommend you read http://castalian.wordpress.com/2008/01/07/the-death-of-windows-forms-part-1/ and http://castalian.wordpress.com/2008/02/19/windows-forms-still-ahead-of-wpf-in-lob-applications/

    I am just about to start writing part 2 to the death of windows forms.

  5. The Death of Windows Forms - Part 2 « Castalian Says:

    [...] The proprietor of said company (Philip Wright) has now chosen to construct a disquisition into WPF adoption. I have chosen to go a little further into reasons Philip states as [...]

  6. Keigan Says:

    I happen to be equally comfortable in photoshop and illustrator as I am in VS (admittedly without an IDE I would be lost) so I love being able to do pretty much anything I want in WPF. That really is what it offers… a tangible way to make beautiful UI possible. It creates that connection.

    I also recognize that I am rare. Most of the developers I work with either can’t or have no real desire to make things visually compelling. I also don’t think most coders have access to a designer, at least one who gives a damn about what the coder is doing. That said, it is going to take more than just showing people the art of the possible… it will take time and (I think more importantly) better tools to get any widespread acceptance.

  7. Georgi Says:

    Let me mention one more thing why WPF will be adopted slowly – it has outstripped the hardware an average office and home computer has. It behaves (regarding performance) nice on a system with good 3D-accelerated adapter but will lag as hell on a slower computer where software-emulated rendering is performed.

    Let me mention that I do love the way WPF is implemented – it strictly follows W3C DOM 2 specifications (http://www.dmoz.org/Computers/Programming/Internet/W3C_DOM/Specifications/). There is a true Model-View-Controller architecture which makes the GUI layer as detached from the underlying OS as possible.

  8. Judah Says:

    I didn’t say WPF databinding is perfect; rather, it’s a hell of a lot better than WinForms binding.

Leave a Reply