Even though WPF has been around for a number of years, there is still some confusion as to what WPF is and what it is not.  Here are a few items that come to mind:

What WPF is

• A replacement for Windows Forms.  If you’re going to be writing applications for the Windows desktop (as opposed to the web), you need to learn WPF.  Microsoft has spent a considerable amount of resources (both in time and money) making WPF their “go-to” solution for the desktop.  Don’t avoid learning WPF because you think it’s an ancillary technology.  It’s not.  For a desktop programmer to ignore WPF is akin to a web programmer ignoring ASP.NET.  Sure, you can do it, but it’s a decision to abandon most of Microsoft’s technology stack for that target platform.
• A paradigm shift in programming.  I don’t know of any developer who has picked up WPF and said, “this isn’t so different” because the simple fact is that it’s not only different, it’s a complete change in how you approach user-interface development.  In many ways, it’s closer to web development than WinForms. This is partially due to XAML introducing declarative interface programming to the desktop, where previously your typical developer only saw it on the web or esoteric, domain specific environments.
• The future. Like it or not, WPF is here to stay.  As I said previously, Microsoft is betting the store on Windows Presentation Framework.  Ok, maybe not the whole store, but after being “out there” for over 3 years, Microsoft is putting WPF on all of its new operating systems (including the new Windows 7) and even Visual Studio 2010 is written with WPF.
• Stable. It’s to Microsoft’s credit that .NET 3.5 and .NET 4.0 didn’t bring significant changes to WPF.  There wasn’t a whole lot that needed changing, aside from largely internal core issues such as performance.  Further, there were virtually no breaking changes from version to version, especially when compared to the migration from .NET 1.0 –> 1.1 –> 2.0.
• Robust. There is very little from a user experience (UX) perspective that WPF doesn’t make possible.  This even includes 3D, Animation, Surface, and in 4.0, multi-touch.
• Hard. The best technologies are rarely easy and WPF is no exception.  You have to change the way you approach both UI design and development.  And you do have to change the way you think. It’s no exaggeration to say that WPF comes with a very steep learning curve.  Fortunately, once you get past the paradigm shifts and really begin to grok some of the fundamental concepts, your development time should drop dramatically and you will begin to see a good return on your investment in development time as well as the quality of your output.

What WPF is not

• Cross-platform. WPF runs on Microsoft Windows only.  Is that limiting?  Not really.  If you exclude mobile devices, you still have about 94% of the operating systems/desktops and that’s certainly nothing to sneeze at.  Windows 7 releases soon and is getting wide praise (especially compared to Vista) and I expect that Windows’ market share will increase.  Also, WPF’s single-platform focus doesn’t place needless constraints on the technology the way Silverlight does.  With WPF, you don’t have to dumb-down your application for a very small minority.
• Silverlight. The Silverlight/WPF argument is akin to the chicken/egg one.  The fact though is that WPF did come first.  They’re doing a great job at bringing much of the WPF functionality to Silverlight, which does give you an option if you need cross-platform functionality, but there are still quite a few things that WPF does better or simply does that Silverlight cannot do at all.  I’m going to do a post or two on those differences in the near future.
• Slow. All things are relative.  Yes, compared to many WinForms apps, WPF could be considered slow.  But you know what?  Compared to console applications, GUI’s are slow.  Compared to straight HTML, Javascript is slow.  Compared to Javascript, server controls are slow (generally).  You’ll have to forgive my annoyance, but the “slow” arguments are the same ones I heard tossed at Excel by people who were still determined to use 1-2-3 and by Netware guys who didn’t like Microsoft and/or NT.  The fact is that most current desktops run WPF just fine when the application is well written and that’s always been the case.
• Mobile. The only way to make WPF mobile (like cross-platform) is to compromise features.  This gets back to Silverlight which is a subset of WPF’s functionality.
• A language. I know to some I’m being pedantic and nitpicky, but I’m really not.  You don’t write an application in WPF, you write it for WPF.  The distinction might seem minor on the “surface” (insert groan here), though it’s not.  I can write an application utilizing the WPF frame work in any number of languages, including C#, VB, F#, IronRuby, or any other language that can call the .NET stack.  Conversely, I can’t really write a WPF web application, service, or console app.  WPF is the technology, languages are the means of accessing that technology.
• XAML. This one is for those who thought, “what about XAML?” when I said WPF isn’t a language.  Nope.  XAML is the language, again, the means of accessing the technology.  You don’t even need XAML to write a WPF app.  In fact, knowing how to do so is (in my opinion) an essential skill if you truly want to understand WPF.  Ironically, I believe that in order to really understand how XAML is used for WPF, you should know how to write WPF apps in procedural code.  There are books that can help you do just that and I’ll get to that in a few posts.
• Going Away. I’ve been listening to so-called pundits sounding the death-knell of desktop apps for over a decade.  This is because people like Larry Ellison and anyone sitting in their mom’s basement pounding the refresh key on Slashdot have seen thin clients and now RIA as the key to taking Microsoft down.  There will always be a need for desktop applications, at least well-written ones.  When given the choice between a well-written desktop app (via WPF) and a well-written web application, my experience is that people will choose a desktop application every time, unless there’s a business reason that requires web functionality.  Even then, if you (the developer) know what you’re doing, most of that functionality can be done on WPF.

The Bottom Line

There’s a great saying that says, “when all you have is a hammer, everything looks like a nail” and that’s how a lot of developers and consultants respond to business problems these days.  I can’t count the times I’ve heard times I’ve heard, “I bet I can make a web application that will do that.”  Well, I bet I can make a desktop application that runs as a storefront to amazon.com, too.  In fact, I know I can.  That doesn’t make it a good idea.

The problem is that there are a lot of very good web application programmers that are disproportionate to the number of very good desktop application programmers (or those with both skill sets), so a lot of these folks simply validate “web app everywhere” mentality by virtue of sheer numbers.  Think about it.  If you ask a room with 20 orthopedists and 2 chiropractors how to help a person’s back pain, what do you think the “prevailing wisdom” of the room is going to be?

The bottom line is that there is a huge need for quality desktop applications, but there’s an even greater need for developers and consultants who can identify those needs.  Otherwise, it’s hammer time and every requirement is one big fat nail just waiting to be nailed to the world wide web.

Popularity: 42% [?]