WPF vs. Silverlight: Choosing the Right Technology for a Project

by Abel Avram on Jun 02, 2010 |

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.”

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

air by Vic _

You can always try Air or Flash.

Re: air by Abel Avram

Hi Vic,
this post is addressed to the .NET community and it discusses .NET solutions for RIA/desktop, covering only Silverlight vs. WPF. Of course, there are other solutions out there like the one you mentioned.

Silverlight and WPF converging is scary by john zabroski


Implicitly tucked into your post is the hand-on-brain mind control suggestion that converging Silverlight and WPF removes confusion. WPF is in my experience too big for its own britches. One of the former WPF employees, who now works at Google, referred to it as "too big to reimplement", suggesting nobody would ever even want to copy WPF. Silverlight, in my experience, is much lighter and more object-oriented. WPF, on the other hand, is a mixture of object-orientation and "the architect's kitchen sink". WPF has things like DataTemplates that can promiscuously search WPF's built-in Inversion of Control Container (style dictionaries) based on criteria, etc. It just leads to really brittle design and applications crashing or going into an inconsistent state on null pointer exceptions when resources can't be found. In short, WPF has WAAAAAAAAAAAAY too much cyclomatic complexity. It is no wonder Miguel de Icaza told Microsoft that there was no way in hell Mono would ever bother to implement WPF. Microsoft could not even re-implement WPF from scratch, if they tried. It is an accident, carried through to perfection.

Most of what I want from WPF is access to milcore and the use of retained mode graphics and more featureful hardware accelerated rendering. THAT is all I need to hear from Microsoft: Are you going to converge Silverlight and WPF by slowly chopping off WPF's warts and slowly making Silverlight more robust? Some indications are that MS is not afraid to deprecate dumb ideas, like BitmapEffects.

Re: Silverlight and WPF converging is scary by john zabroski

I would also add:

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.

Choosing really depends on you having WPF and/or Silverlight programmers readily available. This should not be their first rodeo in WPF or Silverlight. If you put a young cowboy on a bustin' bronco, you'll be depending on the clowns to save you.

I've told people in the past this: If you expect me to provide you with a flow chart on when to choose Silverlight or WPF, you are out of your mind, please quit IT. Do not depend on some stupid flow chart. If you are confused about what technology to use, it is because you lack experience. Your project will be late, due to lack of experience. UNDERSTAND THAT. And stop asking for a flow chart that will decide your fate for you. It most certainly will assure your destiny is failure.

Re: Silverlight and WPF converging is scary by Abel Avram

I quoted Ian Ellison-Taylor, GM at Microsoft, and he mentioned convergence. I suppose he knows what he is talking about. And I think that is the natural tendency. There is a reason Microsoft advertises Silverlight everywhere, but they say little about WPF. How they will converge? One possible way is for Silverlight to borrow some of WPF's code and features, completely replacing WPF. Silverlight will be used then to generate builds for the desktop, the browser and the cloud.

Re: Silverlight and WPF converging is scary by Abel Avram

you are right about the need for experience to venture into a project, but the problem with new technologies is that nobody has experience when such technologies first appear. And companies start such projects and learn along the way. Also, there are degrees of knowledge. One may know many things about a technology, but he might not know everything. A chart showing the differences between WPF and Silverlight is helpful for them. If you know those technologies like the back of you hand, then fine, you don't need the chart, but if someone does not know everything, such a chart may help him avoid mistakes.

Re: Silverlight and WPF converging is scary by john zabroski

You're funny.

You are the one re-quoting Ian as if what the Microsoft management's public statements matter. Hello, have you ever heard of DirectX and WinG??? Linq 2 SQL and Entity Framework??? What other examples do you want of the fact that technical decisions at Microsoft are not made in technical terms but rather political terms and on the strength of the wishes of their largest customers.

Here is what will happen. Silverlight's programming team, the ones most fervently in support of a lighter WPF without all the dumb stuff, will lose. Big WPF Customers will constantly complain to GMs like Ian about how dumb Microsoft is for having two APIs, and how everything they need to do can be done in WPF. Who cares how dumb WPF is. We need quicker release schedules! Who cares about bugs. We need quicker release schedules!

I will repeat that just re-quoting Microsoft is passing the needle in the opiate circle.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Educational Content

General Feedback
Editorial and all content copyright © 2006-2013 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy