WTF is WPF?
If I said "Windows Presentation Foundation" to you, you're more likely to think WTF than WPF, right?
To me, the name "Windows Presentation Foundation" says very little. Even now I know what it is, it still means nothing.
When you first launch Visual C# Express and start a new Project, you see this choice of project types:
Only having a vague idea what I was doing I looked through the description of each option and plumped for a Windows Forms Application as the one for me. Having looked at the WPF option and learning it was "Windows Presentation Foundation", as above, I quickly dismissed it as not for me.
What I would have found more useful is something like this:
If only things were in plain English, hey?
WPF?
This all came about last week after I mentioned I'd gone native and Martin Davies suggested I looked at WPF, which he described as "next gen Windows Forms".
Having taken a very quick look at WPF I instantly decided it was much better suited to my way of working.
Developing Windows applications with WPF is a lot like developing in Flex (or even XPages I guess). In that the GUI is defined by an underlying XML-based markup. Just like Flex has MXML, WPF has XAML.
Here's what creating a WPF Window looks like in Visual C# Express:
For anybody used to developing in Flex, this IDE should be instantly familiar.
Developing in WPF, as a seasoned Flex developer, I've been like a duck to water. Naturally there are some key differences that take a bit of getting used to, but you can't expect to pick something new up without having to learn a few new ways.
If I get chance I'll do a quick screencast to show just how easy it is to create database-driven Windows apps.
In short, if ever you need to go native for any reason, WPF is probably your best route. Thanks to Martin Davies for brining this to my attention.
Skip to the 
You can subscribe to an individual
This may just be heresay as I have not actually worked on a WPF application, but the general impression I received from others in the office when it has been mentioned was that it was a bit slow and a bit clunky on "older machines" compared with windows forms.
I do use one application written in WPF and it is horribly laggy, but perhaps it is just a badly written bit of software as the hardware I am working on isn't particularly rubbish.
Reply
Hmm, can't comment. It's not an issue for what I'm working on, but I'll keep it in mind if ever I need to "go native" again.
Reply
Also. I've been developing on a Win7 machine with 8G of RAM. As you'd expect my WPF app runs fine.
I've also been testing it on a WinXP VM with 512MB of RAM. On there it runs fine too.
I guess it depends what it is the apps doing just as much as it does what it was built with.
Reply
Hide the rest of this thread
"I guess it depends what it is the apps doing just as much as it does what it was built with."
Add to that "how it's written". It's equally possible to write a horribly performing native C application as it is one with a nice safe framework. Your long history of identifying and working around inefficiencies inherent in the system (witness the repression inherent in the system!!!) should serve you well when it comes to chasing down the odd poorly performing bit you're likely to encounter with WPF. I would expect most problems these days to be with how one goes about working with data since most of the UI is so thoroughly abstracted away from you when it comes to the actual compiled result.
Reply
Windows forms descends, if memory serves, from the MFC (Microsoft Foundation Class) which is ancient. WPF is very young by comparison and made to take advantage of newer machines and related specs, so the criticism is valid and unsurprising.
Reply
The one significant app that I have written in WPF appears to perform fine on older Windows XP machine as well as more modern kit. Certainly t was as easy as any other app dev tool to come up with slow code.
Reply