WPF or Silverlight? In the End, It's All Just XAML

I'm often asked about the rivalry between Windows Presentation Foundation (WPF) and Silverlight. Which one will win? Which one is better? The reality is that they're actually two sides of the same goal of building richer user experiences in applications, no matter how they're deployed. Under the hood, it's all just XAML.

Looking back to the beginnings of WPF (when it was code-named Avalon) in 2001, WPF actually was a culmination of a number of movements in development within Microsoft. One was to move beyond the DHTML experience of HTML 4, which today is being addressed by HTML5, but back in 2001 was just a distant mote on the horizon. There was also the issue of the Windows GDI being a rather archaic way of drawing things on a monitor—essentially unchanged since the days of Windows 3: Something new needed to happen. DirectX was a workaround to let games take advantage of the video cards of the day, but Windows itself didn't (and couldn't) utilize it.

Even before WPF shipped in 2006, WPF/E (Windows Presentation Foundation/Everywhere), the code name for the product eventually known as Silverlight, was under development. The code name says it all: Silverlight came from WPF. But it's important to note that both web and Windows were factors in the design of WPF from day one, and Silverlight was a natural extension of that vision.

So how do we get a rivalry from what is clearly the common origins of WPF and Silverlight? I think the issue lies in the slow adoption of WPF and the much more rapid adoption of Silverlight. Developers have been slow to embrace WPF for a variety of reasons. WPF represents a very large leap in the way UIs are built if you're coming from a Windows Forms world. In some ways, the maturity of WinForms has impaired the adoption of WPF—the WinForms tooling is so good that getting a parity of features between the WinForms designer and the WPF designer, to this day, has not been achieved. Also, the UI specification for WinForms is a known science. Microsoft long ago published a specification for what is now known as the "battleship grey" UI. Developers understand this UI and can build it on their own. WPF does not, and likely never will have, have a UI design guide specification.

On the Silverlight side of the world, developers building for the web have always battled difficult tools for UI design and for the most part have always had to dance with the web designer to get a great-looking website built. Silverlight also brings the CLR to web development, giving developers a chance to work in a .NET language to build clients, rather than deal with the vagaries and diversity of JavaScript and varying browser DOM issues. So there are clearly compelling reasons for developers to grab onto Silverlight quickly: It addressed pain points they had in web development.

Silverlight also supports cross-platform development, providing a client solution for the Apple Macintosh, and even more recently for the Windows Phone 7.

But in the end, it is all just XAML; as both WPF and Silverlight have evolved in versions, they've been sharing features back and forth. WPF 4 got UseLayoutRounding from Silverlight 2, for example. Developers working in WPF 4 and Silverlight 4 find their skills pass back and forth better than ever.

Maybe the time has come to retire the terms "WPF developer" and "Silverlight developer." I think the time has come to call ourselves XAML developers.

For a great summary of the history of WPF, check out the Channel 9 video with Michael Wallent.

Richard Campbell is technical director of DevProConnections, cofounder of Strangeloop Networks, cohost of .NET Rocks! (www.dotnetrocks.com) and host of RunAs Radio (www.runasradio.com). He has more than 30 years of high-tech experience and is both a Microsoft Regional Director and Microsoft MVP.