BT

Your opinion matters! Please fill in the InfoQ Readers’ Survey!

WPF vs. Silverlight – What Really is the Difference?

| by Jonathan Allen Follow 641 Followers on Nov 08, 2009. Estimated reading time: 1 minute |

As both WPF and Silverlight increase in importance among .NET developers, the confusion about the difference between the two has also increased. Back in June Wintellect released a little known but incredibly important whitepaper on the topic simply titled Microsoft WPF-Silverlight Comparison Whitepaper. While we recommend GUI developers read all 69 pages, we offer you a summary of the major ones that impact line-of-business developers.

Dependency properties are a key component of both platforms, with PropertyMetadata being used to back properties instead of normal fields. While Silverlight only offers this one class, WPF has some subtypes.

  • UIPropertyMetadata adds a flag that determine “whether animations should be disabled on the dependency property where the containing metadata instance is applied.”
  • FrameworkPropertyMetadata adds flags to indicate the property affects the pipeline including control arrangement, measuring, rendering. It can also indicate whether or not data binding is allowed on the property and what type to default to. Since Silverlight doesn’t support this class, all data binding defaults to one-way.

Silverlight doesn’t support tunneling events. Both platforms support direct and bubbling events.

WPF supports several types of triggers. A basic trigger attaches to a dependency property and automatically applies style changes when the trigger condition is met. In addition to basic triggers, WPF also supports triggers that respond to routed events and triggers that work with data-binding. Instead of triggers, Silverlight uses a technology called Visual State Manager instead. WPF doesn’t currently offer this, but will in WPF 4.0.

Silverlight only supports a few markup extensions. In addition to the shared StaticResource, Binding, and TemplateBinding extensions, WPF adds DynamicResource, RelativeSource, x:Type, x:Static, and x:Array.

There are numerous keyboard and mouse events only available in WPF. As there are far too many to list here, we will defer to the full text.

UIElement class and the IInputElement interface. When a control is disabled, WPF uses this to disable all of the child controls. Silverlight doesn’t offer this behavior, so developers have to walk the control tree manually.

On the communication side, WCF in Silverlight is limited to BasicHttpBinding and PollingDuplexHttpBinding. WPF, of course, supports all of the available bindings.

Finally, printing is completely different in WPF and Silverlight. WPF allows the direct printing of visual trees while Silverlight relies on the browser.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login 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

More on the subject by Alan Mendelevich

I'm currently writing a series of blog posts on code reuse between WPF and Silverlight. Table of contents can be found here.

Re: More on the subject by Jonathan Allen

I'm looking forward to reading it, the source I cited was released before Silverlight 3 was complete and needs to be updated with the final feature set.

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

2 Discuss
BT