Early in my programming career, we had a choice to make at the beginning of each project: do we do this as a command-line/console app (prompt and response), use a DOS windowing library, or do a Windows 3 native app?

Eventually, it became the norm to do a Windows app by default, and fall back to command-line only if you need to call it from batch files. The idea of creating prompt & response console app fell out of favor for all but university programming projects and small utilities.

It was the evolution of the user interface, and the evolution of user expectations. The better applications became, the more users expected out of the next one. User interface platforms kept up as best as they could from command-line to screen-oriented to 80x40 windowed to graphical windows to HTML/AJAX to RIA.

I first started getting paid to develop programs back in 1992. Before that, it was just all fun and games going back to 7th grade and my time on the Commodore 64 (the source of the name for this blog) Over those years, I think I've kept up fairly well with the advances in user interfaces primarily on the Windows platform (I dabble in Linux every once in a while, but it has been a while since I compiled anything serious in gnu c++, and I've never done anything on a Mac but record music with a MIDI synth). While I certainly don't claim to have prescriptive guidance for everyone, and I don't claim to represent any opinion but my own, I thought I'd put down a few thoughts as to what types of applications each modern user interface approach is best suited towards.

When reading below, remember to keep an open mind. Nothing here is set in stone, and I'm sure we could come up with a million exceptions, especially when existing codebases are involved. Knowing the basics, however, will help you make good user-centric and IT-friendly decisions as to what platform to target when dealing with those exceptions. Also keep in mind that I am a Windows developer. The majority of what I and my teams write is run on Windows - even the Internet stuff (Windows XP still runs something like 80% of the computers on the Internet). I am not a Java developer or a Flash developer - the last non-Microsoft IDE I spent any serious time in was Borland C++ (I think v3 or v4 in the huge blue box) back when OWL was all the rage, and Delphi 1.0 :)

When to use WPF

For most Line of Business (LOB) applications that run only on Windows, my default starting point is WPF. Prior to WPF, my default starting point was Windows Forms. The prevalence of HTML applications inside enterprises came about primarily because deploying old VB6-style applications was a royal pain. When .NET came along, the die had already been cast and many companies, burnt by DLL hell, started going with HTML applications.

.NET avoids those deployment issues. I won't go into detail here, as there are lots of other great references on how to use ClickOnce for on-demand, or numerous other technologies for push updates.

Users also started demanding something nicer looking than battleship gray. To them, HTML apps were modern apps. Unfortunately, many of them didn't realize that even the simplest desktop-like functionality was usually very difficult and/or costly to implement in HTML applications. In the early days, it was all about "look like Office" (just look at how many office toolbar controls were for sale at any given moment). In fact, I can't even begin to count the number of developer-designed applications put out there as UI-clones of Outlook (I'm guilty of a couple of those from way back too). Luckily, users have moved beyond that.

So why would I default to WPF when it has a learning curve (if you haven't climbed it yet) and is relatively new, having come about only with .NET 3.0? Here are some of my reasons:

1. The web and the advent of RIA has raised the bar for what users expect to see in an application. It's a proven fact that the look and feel of an application greatly contributes to its acceptance and to users' opinions of the application. Of course, a great looking application that doesn't work isn't going to fool anyone, so it's important to note some of the other things that WPF brings to the table. I've gone through great effort and expense in the past to make Windows Forms apps look like branded web applications, but still provide all the richness, performance and functionality of a desktop application. In WPF, that's cake.
2. Binding in WPF is great. Data binding still suffers from (again) the VB6-era stigma. WPF binding - to objects, to properties of objects, to data etc. is far more advanced than anything that could be found in Windows Forms or old VB6 apps.
3. XBAPs are relatively painless to install. If you are find with living in a sandboxed environment, and want to keep a browser-hosted model, WPF XBAPs are a great technology to consider. You still get access to much of the .NET framework and the richness of full-blown WPF. As a browser-hosted application, you lose some access to client-side resources, but you gain the ability to put the application on a web-based intranet (or extranet or even Internet if you have Windows-only customers) and provider users with a URL to access the application.
4. The application is interactive, and not just publishing HTML content (note that if the format can be negotiated, WPF has superior text document support, but it isn't actual HTML).
5. WPF applications actually make good use of client resources. Straight HTML/AJAX browser applications are more bandwidth-intensive than processor-intensive - they push most processing cost up to a central location rather than federating it out.
6. Given equivalent skillsets in WPF and HTML/AJAX applications, the WPF application will typically be quicker/cheaper to develop and have better response time and richer functionality vs the HTML/AJAX application.

Of course, WPF also excels in kiosk-style applications (in store, ATMs, etc), rich display (like the airline status at the airport or the sessions listings at conventions), and general "WOW!" applications. Chances are, if you're targeting an application like that, you're already familiar with what WPF brings.

So, by default, I start at WPF. WPF is the fully-enabled technology. With the exception of cross-platform, it is the superset of the other approaches offered below - most everything else is a compromise in one area or another. WPF is the technology most likely to be able to keep up with changing requirements and to provide me the most flexibility when working with the users to define the user experience, so it is the first one on the list when looking at new applications. In short, when I start with WPF, I don't have to say "no" to the stakeholders anywhere near as often.

If you haven't yet seriously looked at WPF, I encourage you to do so, especially with the added features of .NET 3.5. Scott Guthrie also hinted at some announcements around WPF at MIX, so I look forward to see what else is coming this year. Third-party vendors are creating some great controls for WPF, including a multitude of grids and other common controls. Now is a great time to get into this technology.

When to use Silverlight

Next stop is Silverlight. I and others have written a ton about Silverlight in the past, so I won't go into great detail about what Silverlight is here. In a nutshell: Silverlight 2.0 is a cross-browser, cross-platform browser-optimized version of WPF.

I choose Silverlight 2.0 when the following are true:

1. The application must be browser hosted (ie, a "web app")
2. The application must function cross-browser and/or cross-platform OR it must seamlessly integrate with an existing web-based environment such as Sharepoint as a component of a larger page. (Think a product viewer on an eCommerce site, or perhaps a way to draw on a map, or view an interactive graph/scorecard). If it doesn't require in-page integration, you can still go with a WPF XBAP if you are Windows-only.
3. The application is not primarily a text-centric application (in other words, you're not just displaying non-interactive HTML text content)
4. The schedule for production deployment fits within the Silverlight 2.0 deployment schedule. (Obviously, this will become a non-issue in the future, but it is a legitimate consideration right now)

I recommend using Silverlight 1.0 when the above are true, and in addition, the following are true:

1. The application must be deployed on released technology prior to the release of Silverlight 2.0
2. The application is primarily media or mouse-centric (video, animation, games, etc.) or
3. You want to use Silverlight as a presentation surface for an AJAX/HTML application and don't want to rewrite all that JavaScript code.

The advent of the <asp:Silverlight> and <asp:Media> controls in the ASP .NET 3.5 extensions make putting Silverlight applications and Silverlight media players on your site a snap. The Visual Studio 2008 extensions for Silverlight make building your applications easy.

I tend to categorize Silverlight applications very broadly into Full Applications, Sites, Page Components, and Site Integrated Applications

Full Applications are exactly what the name suggests: a full-blown desktop-like application. Think of it as a desktop application hosted in a browser. This classification also often includes games. This is the area that RIA most often refers to.

Sites are very much like full applications, but are more about presentation of content vs. gathering of information. Flash developers have been creating flash sites for years, and this would be the Silverlight version of that.

Page Components (parts, gadgets, applets) are smaller pieces of larger pages. Examples include ads (of course!), product viewers, image slideshows, graphs, media players etc. I also tend to include Vista sidebar gadgets into this category.

The distinction between Site Integrated Applications and Page Components is a bit gray. It's primarily a matter of size and scope. An integrated application might be a survey as part of a larger site, or a product listing (listing of all products meeting search criteria) on an eCommerce site. These are pieces that are essential to the functioning of the site within which they exist, and are directly in the typical workflow.

What about Good Old HTML/AJAX Applications?

First, why do I call them HTML/AJAX applications instead of "Web Applications"? Simply, it is because the term "Web Application" includes things like Silverlight, Flash/Flex, Java apps etc. The term is broad enough to encompass any cross-platform browser-hosted application.

There are a few places where HTML/AJAX applications stand out:

• You need to target a platform not supported by WPF or Silverlight
• Your talent pool consists primarily of JavaScript programmers, not .NET programmers (although Silverlight 2.0 DLR will mitigate some of this)
• Your applications are primarily about presentation of HTML content.

I have to admit right here (again), that I am biased against doing all but the lowest-barrier to adoption Internet applications using HTML/AJAX. While my decision criteria starts at WPF and eventually moves down to HTML applications, many people's starts at HTML and never goes anywhere else. Unfortunately, even with modern AJAX libraries, HTML/AJAX applications require more diverse skills (.NET + JavaScript) than .NET-only solutions, and are still more difficult to program.

Anyone who has developed a serious AJAX application, beyond just an updatepanel or accordion, can attest that the amount of client-side JavaScript that goes into such an app, combined with the server-side JSON services, makes them difficult both to develop and maintain. As a consultant, I can attest to the fact that such applications cost more to develop than Windows Forms or WPF applications of greater functionality.

I can understand the skillset issues, but AJAX itself is relatively new, so the folks doing AJAX programming are generally smart, talented people that are able to adapt and learn new technology if they are allowed to do so.

I'd encourage folks currently programming everything in HTML/AJAX to consider migrating some of the functionality to RIA platforms like Silverlight, or on the next major rev, consider even porting to WPF if the target audience is appropriate for that technology. An exciting aspect of Silverlight is that it plays nicely with your AJAX applications, so you can combine the two while making the migration. Plus, once everything is in Silverlight, you can easily port to WPF if your target platform changes in the future, or stick with Silverlight and rest assured that you now have a skillset which can be used to target both desktop applications (WPF) and browser applications (Silverlight).

Remember, AJAX wasn't about replacing the desktop, it was about building a better web application which could behave more like a desktop application. Silverlight (and Flex and similar RIA technologies) are natural evolutions of what AJAX started, and at least with Silverlight, they have a richer model that addresses many of the shortcomings of AJAX.

Don't Forget Windows Forms!

... but consider that it won't hold the same place going forward that it once enjoyed. The proliferation of web apps knocked Windows Forms to the back for a bit, and now WPF has taken over the desktop development platform for many applications.

Windows forms is great when you have a utility application to write, or something which simply doesn't require a modern user interface because it is used once in a blue moon, or its utility is primarily in other areas (like a report launcher/viewer) where the content is the user experience.

That all being said, Windows Forms applications are still simple and quick to program, and are a great choice when schedule and cost are the most important drivers.

Made it This Far?

I hope that helps you out when deciding on the platform your next project should target, and at least a recommended order by which to consider platforms in future projects. I welcome and encourage thoughtful comments and feedback - whether you agree or disagree.