Silverlight has come an amazing distance since the initial 1.0 release and 1.1 alpha (controls? who needs controls?) just over two years ago. It’s hard to believe that we’re on Silverlight 4 in such a short time. It’s even harder to believe that each of those releases has been robust and packed full of new and useful features, driven by community feedback.

With all the attention given to Silverlight, it’s reasonable to wonder what is happening with WPF. WPF, being the more mature technology, tends to have quieter releases with less fanfare. That doesn’t mean the feature set isn’t impressive, though. 3.5SP1 was a great release, and just take a look at what we shipped with WPF 4 beta 2:

• DataGrid, Calendar, DatePicker
• Visual State Manager (pioneered by the Blend folks and tried out first in Silverlight)
• Touch input in the core base classes
• Touch Manipulation input in UIElement-derived controls (scale, rotate, etc.)
• Layout Rounding
• Cached Composition
• Pixel Shader 3 Support (PS3 supports some pretty intense effects. I hope to see it supported by Silverlight as well at some point)
• InputBinding and KeyBinding
• Binding Run.Text
• Binding Dynamic Objects
• Easing Functions
• Xbap access to HTML and scripting, as well as Xbap full-trust elevation prompting
• Windows 7 Integration with the TaskBar using System.Windows.Shell
• A completely new text rendering stack giving us pixel-perfect clear type text as well as better support for animated text and control over snapping
• A completely new Xaml parser
• A much tighter and smaller client profile install (a .NET 4 feature)

Two of the flagship design and development products at Microsoft have taken advantage of WPF, and there have a pretty heave dependence on the technology:

• Expression Blend : written from the ground up in WPF
• Visual Studio 2010 : the user interface was completely removed and replaced with a great WPF version

At the PDC, we also saw other WPF-based applications such as Fishbowl and Microsoft Live Labs Pivot (which uses seadragon/deep-zoom technology). I’ve also seen a number of other applications, written by partners, that do some great things only possible with WPF. I’ll have Channel 9 videos up for those soon.

WPF 4 is the best and easiest way to write full Windows 7 applications in .NET. If you want to write managed code and target Windows 7, this is the technology you’ll want to consider first.

So, as you can see, WPF development is alive and well both internally at Microsoft with the partner community. It may not get the level of attention that something new and fast-moving like Silverlight gets, but it is there, and it is strong.

My Role, and my Preferences

In my role as the Developer Community Program Manager for Windows Client, I tend to focus on WPF, as it is the biggest group in my area. However, my role is not limited to that: C++/native, WPF, windows forms, some Silverlight, Windows 7, 8 and more (when I joined, no one was talking about the current version of Windows, they were already moving ahead on the next version) sprinkled with a little surface and maybe even some mobile, all fall under my umbrella. Jaime Rodriguez is my counterpart on the Evangelism side, and is responsible for some amazing WPF and Windows 7 content.

When it comes down to it, I love both Silverlight and WPF. I have no skin in the game regarding which one you choose, as long as you are choosing the one that will meet your feature and usability requirements while giving you the productivity you need. For example, writing a bunch of COM wrappers to access things Silverlight doesn’t natively support, and then having to deploy those wrappers as MSIs alongside Silverlight, would make me question if you had picked the right technology. Similarly, if you’re considering Xbap, you may want to look into Silverlight and see if does what you need.

What the Future Holds – Convergence of WPF and Silverlight

I recently spoke with Ian Ellison-Taylor at Microsoft. Ian is a General Manager at Microsoft, reporting directly to Scott Guthrie. Among other things, his group handles both Silverlight and WPF (and RIA services and a lot of other stuff). I figured if I wanted the skinny on the future, he’d be the guy to talk to. So, he and I talked about the convergence of Silverlight and WPF, and later exchanged some email on the topic.

In the future, it is very likely that both Silverlight and WPF will be a single technology with a single codebase. After all, Silverlight was originally known as WPF/E (E as in Everywhere), and in an amazing 180 degree reversal of our usual approach, we took an ugly codename and created a great product name (Silverlight) from it.

What does that mean, from a practical standpoint?

To developers, it doesn’t really mean much at this point. Your investments in WPF development for Windows and Silverlight for cross-platform applications are both safe. Microsoft is committed both to creating a great cross-platform experience, as well as ensuring that there’s a developer platform that can take full advantage of everything Windows has to offer.

Build for the requirements you have today and understand that there will be a path to the future regardless of whether you picked WPF or Silverlight.

When will this happen?

That’s hard to say. Work in this area is very early, so it’ll be a bit before the public notices anything come out of this. We’ve already seen code shared between the two platforms (VSM, and DataGrid for example), as well as ideas. The two platforms have really helped each other grow. However, Silverlight doesn’t currently support many of the things to build a large application like Visual Studio, and WPF doesn’t run on a cross-platform CLR, so the under-the-covers delta between the two is still pretty big. Microsoft isn’t going to drop real features we’re using today.

What will the converged technology be called?

It may be called Silverlight, or it may be called Windows Presentation Foundation / Everywhere Cross-Platform and Windows Editions. It’s hard to say. We’re funny about names :)

So, what should I build my new application in today?

At Microsoft, we don’t really like to tell people “If you are building an X, use technology Y” Invariably, we’d miss some scenario or the advice would be treated as rules rather than guidance. I’m not going to break that trend here. Instead, look at the feature set you have to implement in your application. Consider what types of services you may need to integrate with, what level of access you require to the local machine, whether you require cross-platform support etc. If you create a matrix of those features, it will help point you to the right technology.

Silverlight is on the right of the graph as the best way to target cross-platform RIA. WPF on the left, as the best way to write managed code applications for Windows 7.

Remember that with Silverlight 4 you can now automate anything already on the machine that has an IDispatch interfaces (think Office automation) and that with WPF 4 you now have a smaller and tighter .NET install, that will work side-by-side with your previous .NET installs, making it much easier to consider deploying.

Also consider that with Silverlight 4 and WPF 4, you can now share binary DLLs between the two technologies, making it much easier to share functionality, and deliver optimized versions of your application (a WPF version with more client features and a Silverlight version targeting cross-platform, for example). The skills and tools are the same.

Conclusion

WPF and Silverlight are both technologies with very rich capabilities and a strong community. Pick the one that meets the requirements you have for your project today, and understand that regardless of which one you pick, you’ll have a path to the future on the Microsoft platform.