If you'd rather listen to this month's column as a podcast, you can download it here.
The "Silverlight/ WPF thing" has dominated some serious Internet fodder for years now. The rumors of both of their deaths and their dominance at the expense of each other have been speculated so many times before incorrectly that I believe it is best to regroup. So with this month's column, I will attempt to clarify where you'd use Silverlight and where you'd use Windows Presentation Foundation (WPF).
But first, let me start with defining just what both WPF and Silverlight are. Defining each of them, Silverlight and WPF, will help to clarify the contrast between them. And will help to clarify the roadmap for both of these technologies in the .NET stack.
First, here's what WPF and Silverlight are:
- They are both .NET; just as much as ASP.NET is .NET, both WPF and Silverlight are part of the .NET stack.
- They are both XAML based. XAML, short for Extensible Application Markup Language, is an XLM-like, tag-based language used to define user interfaces. XAML is declarative like HTML. Ultimately for the .NET developer, XAML is nothing more than a way to initialize and construct .NET objects. That .NET object might be a simple button on a form or some other sophisticated part of the user interface.
OK, now I'll try to define WPF—because WPF came first. WPF's code name was "Avalon," and it was initially released as part of .NET Framework 3.0, officially shipping in Windows Vista in November 2006. But what you might not know is that the Avalon was started back in 2001, even before .NET Framework 1.0 was released—from the team that originally developed Internet Explorer 4 DHTML support and the XMLHttpRequest API that enables AJAX. There is an awesome video interview on MSDN's Channel 9 site of Michael Wallent—the GM of the Microsoft Avalon Team and one of the original architects of WPF and Silverlight. When you are done reading my column and want to dive deeper into the WPF/Silverlight thing, I strongly encourage you to watch that 45-minute interview. In my opinion, it is the most interesting video interview on the entire MSDN site.
The Essence of WPF
OK, so WPF has been around a long time. But—what is it? Well, WPF is a .NET based graphical subsystem for rendering user interfaces in Windows-based applications. "Windows applications" is the key here. WPF is not cross platform; it only natively runs in Windows.
Microsoft has released four major versions of WPF to date: WPF 3.0 (November 2006), WPF 3.5 (November 2007), WPF 3.5 SP1 (August 2008), and WPF 4 (April 2010).
Now many people get confused about WPF being cross platform because it runs on other devices like the Microsoft Surface. But, the Surface is nothing more than a Windows device; believe it or not, Windows Vista runs under the hood. And you will see WPF running on other devices coming from Microsoft in the immediate future. But ultimately, each of those are Windows devices.
OK, so WPF is Windows and its .NET and it's huge. In fact, as far as the surface of the API goes—meaning the amount of .NET Framework classes that exist for WPF, did you know that WPF is as big as Windows Forms and ASP.NET combined? It's huge. In that regard, it's much like the Win32 API, and that is why native programmers love WPF. It's rich, and it's elegant, and there's a way to do most everything, which for a framework like .NET is pretty impressive.
The Essence of Silverlight
So let's switch to Silverlight. Silverlight is a lightweight, cross-platform version of WPF. There are two keys here. The first is "lightweight." Silverlight's runtime packs into a small downloadable package that you acquire in the browser when you first touch a Silverlight site. Silverlight is 4.2mb, and there is a reason for that… because Flash, Silverlight's worthy competitor, is 4.2MB. Silverlight could easily be bigger, but 1) it has to compete with Flash and 2) no one on slow Internet connections wants to download anything huge in terms of runtimes just to use a website or application. So, Silverlight is just a tiny portion of WPF. Typically we say in WPF there are 10 ways to do everything, and that type of breadth makes it elegant—and in Silverlight you can do almost everything and there's only one way to do it, which makes Silverlight elegant in its simplicity.
The second key is "cross platform." Silverlight runs in the browser for broad reach… but not just one browser like Microsoft's Internet Explorer. It runs in all the major browsers on Windows, and it even runs on Safari on the Macintosh. There is no technical reason why there cannot be a Silverlight for every hardware and software platform, and for all we know there probably is. But, it's never all about software. So for example, Apple has decided that no runtimes are legally allowed to run on iPhones and iPads, so we don't have Silverlight for those Apple devices—yet… at least legally. But Silverlight does run natively on the new Windows Phone 7 smartphone. And the parity between the currently shipping browser-based version and the Windows Phone 7 version is excellent. So, if you're building Silverlight apps now, you are already a Windows Phone 7 developer.
Silverlight first shipped in September 2007 and is currently shipping in a 4.0 version. It is the most wildly and widely adopted technically in Microsoft developer history. Microsoft has shipped four major Silverlight versions in just 2 ½ short years. And we are looking at a Silverlight 5 version that will be shipping in a matter of months. If you're interested in a history of all the major and minor versions of Silverlight that have shipped since September 2007, you can download that here.
Interestingly, since Silverlight 2.0, each successive version of Silverlight includes more and more WPF functionality. The Silverlight team of geniuses has figured out how to pack more and more of WPF into that lightweight runtime that runs in the browser.
When to Use WPF, When to Use Silverlight
OK, so there is a little about WPF and Silverlight and how they contrast. I hope that clears some things up. Now, there are exceptions that make things confusing….of course.
First, there's a technology called XBAP, which stands for XAML Browser Application. XBAP allows you to run pure WPF applications in the browser. But, it only works on Windows, and you need all the prerequisites of WPF, such as a locally installed .NET Framework—so I am convinced XBAP was created solely to appease the ignorant CIOs who made silly "browser-based application only" policies for their companies thinking that was a good thing.
Second, since the CLR is open standards ratified, there are a handful of unofficial .NET versions that run on other platforms, such as Novell's MonoTouch for iOS.
Now, third and what has caused the most confusion, is that the currently shipping Silverlight (version 4) runs in a partially trusted way "out of browser." So, yes, in that out-of-browser way, with partial trust, Silverlight looks and behaves just like WPF. This is where so many before have said, "So what the heck do I need WPF for?"
Yes, this is still very confusing messaging to most people. My current guidance is start with the assumption that a new application is going to be out-of-browser Silverlight and work your way back deciding whether you need the deep desktop integration of WPF or the broad cross-platform reach of Silverlight in the browser.
Now, there are some obvious use cases that really demand WPF, use cases where WPF makes the most sense. So I solicited the help of the brilliant engineers of InterKnowlogy and Brian Noyes of iDesign to help me with a list of use cases where WPF makes the most sense:
- real 3D. Silverlight cannot do real 3D.
- when you're migrating from a legacy .NET Windows Forms application and don't have the luxury to "greenfield" it. You have to leverage software assets from the existing system. That is a WPF use case and a deal breaker for Silverlight.
- when you need low-level access to local devices
- when you need to install other local services, components, or drivers that the application uses
- for single-machine deployment in lab or other environments where Microsoft IIS is not allowed, and it doesn't make sense to use a technology that is web delivered
- where your application requires rich interactions, including drag/drop (of app objects other than files)
- where your application needs peer-to-peer calls between client machines or non-callback–based calls from service to client (i.e., client app needs to host service)
- where your application needs secured, non-polling TCP and callbacks
- where your application needs to call existing services that are using full WCF stack features (wsHttpBinding, queued calls, reliable messaging). Silverlight only supports a small portion of WCF.
Does that clear things up (picture me laughing)? I hope it has served to clarify a few things, at least. Now just keep this in the back of your mind because I'll have to write this column again at the end of the year when Silverlight 5 ships. Because when Silverlight 5 ships that list of WPF use cases becomes a lot shorter. In Silverlight 5, you'll even be able to do pure 3D, and there will not be a lot left of WPF that it cannot do.
Tim Huckaby ([email protected]) is founder and chairman of InterKnowlogy, a software and network engineering firm, and Actus Software. He has worked on and with product teams at Microsoft for many years, has coauthored several books, and is a frequent conference speaker.