There is some confusion about when to use WPF and when to use Silverlight. Choosing the right technology for a project depends on precise requirements the application has and the differences between WPF and Silverlight’s capabilities.
Silverlight was initially WPF/E (E from Everywhere), a subset of WPF targeted at web applications running in the browser. Today, Silverlight knows a faster development cycle and it has been kept more in the spotlight, many considering it Microsoft’s platform for the future. Mike Strobel thinks Microsoft created some confusion regarding WPF/Silverlight:
I think the most important thing to improve about WPF is its image. Microsoft should be pushing WPF as *the* platform for rich desktop applications. Instead, it is pushing Silverlight as *the* platform, period. This is misleading to those who are new to both platforms and don't understand that Silverlight is not compatible with standard .NET libraries.
Some even think WPF will die in time, but Brian Noyes, a Microsoft Regional Director and MVP, believes that that is not going to happen in the next couple of years at least. To make a case for WPF, Noyes highlights some of the most important differences between WPF and Silverlight in several areas:
Those are some of the basic capabilities that are different in WPF and Silverlight which should help deciding between the two technologies. Following are a couple of examples collected from developers explaining why they chose one over the other.
Answering to a WPF over Silverlight question, Joe Gilkey explained why his company chose WPF for a project and Silverlight for another:
We have faced this question while planning our software products. The deciding factors for us were whether we needed to access local hardware and/or a local database. For our main product, we need to be able to run 100% locally. We needed to cache information in a local sql database, and access hardware (GPS sensors, serial ports, WCF peer channel, Sync services, etc.) That product is written using WPF. The other 2 products we have in development do not store information locally (with the exception of isolated storage), so we are going the Silverlight route. Both Silverlight products will support out of browser installations. One other factor is that the WPF application is designed to be touch friendly. Thanks to the Surface team, we are able to use the new Surface Toolkit for Windows Touch in the WPF app.
Jeff, another developer, explained why his company started a project with WPF but switched to Silverlight later:
A year ago, we used WPF for a custom client for our multimedia delivery system. In the next year, we will be replacing the WPF for a Silverlight application. Why? Currently most of our application is web/browser based but we needed a static client to handle hardware interaction and a few other esoteric issues. Now Silverlight has OOB which means we can connect to local hardware via COM, problem solved. Why Silverlight vs WPF -- for our customer base, INSTALLATION! Not having to deal with incompatible operating systems and specs, Silverlight just works. And now upgrades are painless, update the server and the downstream client updates. Yes WPF is more powerful, but for nothing that we need.
After presenting the main differences between WPF and Silverlight, Noyes concludes:
The bottom line is that if your client application is mainly a front end for back end data – Silverlight 4 is perfect and sufficient. But if your client application needs deeper integration with the client machine and other things that reside client side, it may be possible to get it done with SL4 elevated trust OOB, but it will likely be more challenging and you may hit brick walls that kill your productivity or functionality. You really need to do a good up front requirements analysis and if you have any significant interaction with client machine resources, WPF is still going to make your life easier.
Regarding the future, Pete Brown, a senior PM at Microsoft, believes that the two technologies, WPF and Silverlight, will eventually converge into one:
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.
When it comes to recommendations, Brown suggestion is similar to Noyes’: “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.”
