One of the first questions that arose from the announcement of off-browser Silverlight was “What will happen to WPF?” The obvious source of this concern is that since Silverlight 3 can run either as part of a Web page or installed in an off-browser mode, why would there ever be a reason to write a WPF application? And since Silverlight seems to be the technology that has all of the new features, is there a possibility that WPF could languish as the ugly step child in the client application development world ?
First, let me assuage your concerns. WPF is not dead. This opinion is based on a couple of on-going development projects at Microsoft: Expression Blend/Design and Visual Studio. In the case of Expression Blend/Design, the entire application was written in WPF. For Visual Studio, the code editors are being re-written in WPF. If nothing else, the investment being made by Microsoft to these products in WPF should demonstrate its on-going commitment to the technology. And there is the on-going integration of WPF into the Live Messenger client to add more fuel to the argument.
Going forward, I see WPF and Silverlight moving ahead more or less in lock-step. Features in Silverlight that are successful will find their way into WPF (Visual State Manager, for example). Features in WPF that are useful will move into Silverlight (element binding, based-on styles). Since the products have different audiences, each technology will be driven forward with a different set of priorities. VB.NET and C# already have this So don’t give up on WPF because of all of the excitement from Silverlight. As a WPF developer, I found some of the excitement generated by Silverlight announcements a little odd (applause for element-to-element binding? WPF has had that for a while now). What playing with Silverlight 3 that I have done so far suggests that the disparity between the two features sets is going to be much less in the future.
That having been said, there is still the open question of when WPF should be used instead of Silverlight 3. I can see three main cases at a minimum, but they all revolve around the same restriction in Silverlight…the security sandbox.
Access to local system resources
Off-browser Silverlight runs in the same security context as on-browser Silverlight. So if your application needs access to the local file system or the communication ports on the client machine, then Silverlight is not going to work out. In fact, this limitation can be extended in include any feature that requires full-trust to operation. Silverlight doesn’t work in full-trust mode. WPF can.
Full 3-D graphics capabilities
With Silverlight 3, perspective 3-D is available. But that is not the same as the complete 3-D capabilities that WPF has. It’s nice, but if you’re looking for fully rotational 3-D images, then WPF is the choice.
Semi-Esoteric Functionality
There are instances where Silverlight is missing functionality that is available in WPF. For example, there is no Closing event for a Silverlight application. This means that you can’t stop a user from closing an application when the current record has been modified but not saved. In on-browser Silverlight, a JavaScript hack can be used to emulate this feature. But in off-browser Silverlight, there is no JavaScript available, so no Closing event can be detected. While might seem like an edge case, the functionality offered by Closing is part of most LOB application. So it might not be such a small deal as you might originally think.
I’m sure there are more differences. It’s not like WPF is not a compelling choice for a development platform. In fact, I approach the choice between the two the same way I would between WinForms and ASP.NET. Because ultimately, the decision between Silverlight and WPF will be based on the specific requirements of a project. If Silverlight (either on- or off-browser) is sufficient, then pick Silverlight. If not, then pick WPF. Regardless of your choice, you’re not in danger of dead-ending with the technology. Both areas will flourish and grow for many years to come.