Originally included with the Windows .NET 3.0 SDK, XamlPad has been extensively updated and is now in version 4.0 under the name XamlPadX 4.0.  Most people will still refer to it as XamlPad though, me included.

To say that XamlPad is helpful for writing and testing Xaml code is akin to saying that a spoon is helpful for eating soup.  You can do it without it, but it’ll take longer and it’ll probably be messy.

But why?  Why would you want to use that when you have a perfectly good editor in Visual Studio?  Good question, I’m glad you asked.

Allow me to take the food analogy a bit further.  Let’s say that you’re a chef.  Come on.  Sayyyy it!  Ok, good.  You’re a chef.  You spend your day making the finest sauces using complex flavors and ingredients.  Yes, I know a saucier technically isn’t a chef, but that’s a subject for another blog, now stop interrupting.

Let’s suppose (saying in my Carl Sagan voice) that you came up with an idea for a new truffle and saffron sauce you want to serve at your restaurant.  Well, you’re a good chef so you’re confident that it’ll be great.  But you also know that it’s an expensive experiment.  The fresh black truffles you want to use are $60 an ounce and the saffron is $63 an ounce.  Even though you know you’ll be able to get it right, you really don’t have the time nor the money to make a full meal, or even the entire dish that would use the sauce if you make a mistake.  So, like any smart chef, you’d make it in a small quantity to get the proportions right first.  This saves you time and potentially a considerable amount of money.

XamlPadX is like that small saucepan.  It allows you to quickly and easily try out your Xaml code without having to make a project with Visual Studio.  It’s fast and it works.

If you’re not using it, then you aren’t as efficient as you should be, it’s really that simple.

Popularity: 26%

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: 34%

I’ve spent the last 5 years writing a blog that was almost exclusively political.  I’ve had a good time with it, but I’m simply burned out on politiics.  I don’t need that kind of anger in my life and since I hadn’t been able to even write a good post in 5 months, I decided that it’s time that I sunset my political writings.

I’m actually quite proud of what I’ve written, but I also know that strong opinions have a tendency to cost opportunities with people who simply do not want to risk that this potentially brilliant software developer is also a complete jerk.  Anyone that knows me realizes that this isn’t the case, but in the marketplace of professional developers, getting to know someone may not even be an option.

So while I’ve put one passion on the shelf, I’ve taken the opportunity to focus on my greater passion, and that is software.  One of the reasons I haven’t written very much on my blogs over the past 6 to 10 months is because I’ve been immersed in a new love.  That love is WPF.

Ok, I’ll admit that I’m crazy that way, and my wife will vouch for that if pressed.  We all have our little quirks and one of mine just happens to be putting markup on the desktop.  (psst!  that’s XAML for those of you in Rio Linda…)

So there we are.  And here we are.  I can honestly say that I have no idea what shape this blog will take, but I’m planning on becoming somewhat of a fairly decent resource on WPF (or at least a place to start) on a variety of areas.  There are some great WPF sites out there, but there can be more.  I’ll link to anything that strikes my fancy, but I’ll also use it to flesh out my own way of doing things in public so that maybe someone else can benefit from my struggles.

One thing I haven’t mentioned is that I’m well in the process of writing a Twitter client in WPF and I’ll be documenting some of that here as well.  I’m not ready to announce the feature set yet, because to be honest, there are some features I’ve got that I’ve always wanted and don’t see in any other twitter clients.

All of this will end up being something that hopefully others will find useful.  Then again, I may be the only one who benefits from it, but that’s ok, too.

So come along and let’s makes some beautiful software together!

Popularity: 5%