.NET & Funky Fresh



  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
There's some darkness in your silver light.

First, let me begin by saying that I'm a huge fan of Silverlight.  I've been working with it since the Alpha 1.1 was released at Mix07.  I've written thousands of lines of Silverlight 1.1 code for a personal project of mine that I hope to share in the not too distant future.  Currently I'm rewriting the project from scratch in SL 2.0 and am enjoying the process.  That said, I've been a WPF developer for about 4 years and its hard for me to look at SL 2.0 without thinking how much more like WPF I wish it could be.

The problem started with the fact that every MS employee with a blog started hyping SL 2.0.  ScottGu even gave an early sneak peak which got me very excited.  I was hoping this was just a small preview, but when Mix08 came and went, there really wasn't that much new news for SL 2.0 (except DeepZoom...which isn't that big of a deal since its already been done in Flash).  Anyways, as I mentioned I've been working with SL 2.0 and I've also been developing WPF apps for much longer (the pre-beta days); which brings me to my point.  If you are a WPF developer (or any developer that believes what MS is saying about being able to convert between Silverlight/WPF) you are in for a few surprises.  Allow me to shed a little light on a few dark areas of Silverlight.

I'm going to start with the three things that I have the greatest concern over in SL 2.0:  Triggers, Styles/Templates and Databinding.

If you poke around a little in SL 2.0 you'll notice that there is a Triggers collection on FrameworkElement.  As a WPF guy, this is exactly what I expect to find.  However, if I take a look at Style, ControlTemplate and DataTemplate I don't find a Triggers collection; I would find this in WPF.  This is a big pain point.  Perhaps you don't see why?  Let me elaborate on one of several important reasons:  WPF's control templating mechanism relies heavily on the ability to define different looks for a control based on triggers.  For example, a button template may change its appearance when the mouse is over the button or when the button is pressed.  If I don't have this ability, how can I achieve a similar effect in SL?  Well, rather than implement Triggers, the SL controls have to be hard-coded to look for special state animations in a hard-coded location of the control template.  What?!  It turns out the control templating mechansim for SL is completely different from WPF; its quite inferior, brittle and cumbersome.  As a result of this design decision, a simple checkbox control asks a designer (or developer) to implement 15 specially named control parts!!!  This is stupid.  The best part is any control templates you build for SL won't work in WPF and any you build in WPF won't work in SL.  And we all know that there is a lot of work that goes into control templates for all but the most trivial (and ugly) of WPF/SL applications.  This is no small issue.



Well, that brings me to Styles.  There are a few things that you might take for granted in WPF that you are going to be surprised to find missing in SL 2.0.  First off, once you set a style, you can't change it.  So don't go trying to let the user pick their theme.  Also, styles cannot inherit from one another.  Not a terribly big deal, perhaps.  But what if I told you that you can't have application wide styles?  In other words, there's no way to specify a default Button style, for example.  Bummer.  Combine those last two and it looks like I'm going to have a lot of repetitive XAML.

Here's one thing that deserves mentioning all by itself.  Property inheritance doesn't work the same in SL as in WPF.  This has the effect of causing problems with databinding because the DataContext property doesn't inherit through the visual tree!!!  Chew on that one for a bit...

Since we are talking about databinding,  I might as well hit the last of my three big gripes.  There's no ElementName binding.  Come on... (Of course there's no RelativeBinding either).

Are you beginning to see how its going to be difficult to move between WPF/SL without major rewrites.  Much of the best-practices and WPF experience I have won't even transfer to Silverlight.  Sure, I understand XAML, but that's the most trivial aspect of learning the technology.  Now I have to develop a whole new set of strategies for building applications that are slightly different for SL than for WPF - even though, on the surface, the technologies look the same.  (It's almost like having to know how CSS works different between IE and Firefox - on second thought, it's exactly like that.)

Let me move on to some lesser (but important to me) features.  I know the SL team can't support everything from WPF, so I'm not surprised that they cut Commands/InputBindings/Gestures.  It just makes me sad...For those of us who are trying to use an MVP/MVC UI architecture approach, this is one feature that helps greatly.  (And a great example of why I have to change my entire UI architecture strategy for SL.)

Here's a few other weird things:

  • You can't create a RoutedEvent the same way as you do in WPF, but somehow the built-in events bubble. 
  • UIElement and FrameworkElement don't have parameterless constructors.   So don't try creating a lightweight control because you can only inherit from Control. 
  • Setting databindings from code is a bit different from WPF. 
  • There doesn't appear to be any printing support.  (Flash has this for a while now.)


Well that just about wraps it up.   There's one more thing that I felt was a little odd.  It has nothing to do with WPF but rather with .NET's core.  There is no [Serializable] attribute or BinaryFormatter.  So you can't binary serialize an object (or create a deep copy).  Somehow I always thought of this as a core .NET feature, but it's not present.

Anyways, perhaps some MS dude with great power will hear my pleas and enact change.  It's not that I don't like SL 2.0.  It's that I'd rather it be good or great than mediocre and be riddled with issues in the future as a result of its presently hacked control templates, etc, etc.  My three big gripes are what I see MS as needing to do to get in the game.  MS is competing with Flash/Flex/AIR/JavaFX, whether they explicitly state it or not and they can't just tag along if they want to make a difference.  (Did I mention I'm a Flash developer to?)  If they want to go beyond just keeping up then they should also consider:

  • Hardware acceleration (I actually think this is pretty important considering all the perf issues WPF has had even though it is hardware accelerated - that doesn't bode well for SL; only time will tell).
  • 3D (People have been begging to get this in Flash for years.)
  • Offline mode (AIR can do it.)
  • Frame-based and better procedural animation (Flash has this)
  • Printing (Flash has this too...)

Well, I guess that's it for my demands ;)  Did I mention I actually like Silverlight 2.0?  I just don't love it.

Posted 03-13-2008 2:50 AM by Rob Eisenberg



tomasK wrote re: There's some darkness in your silver light.
on 03-13-2008 4:41 AM

This is very interesting feedback for Microsoft, they should hear it!

Borek wrote re: There's some darkness in your silver light.
on 03-13-2008 6:28 AM

Great write-up, I'd suggest that you submit this feedback to Silverlight forums or some other place where it can't be missed by MS folks. I agree with your points and would also like these issues to be addressed.


Christopher Bennage wrote re: There's some darkness in your silver light.
on 03-13-2008 10:21 AM

Hardware acceleration in cross platform would be difficult methinks.

I'm trying to remember how difficult it is to theme a control in Flash, it's been about 5 or 6 years since I did that...

DotNetKicks.com wrote There's some darkness in your silver light.
on 03-13-2008 10:23 AM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Rob Eisenberg wrote re: There's some darkness in your silver light.
on 03-13-2008 11:43 AM

Yes.  Hardware acceleration would be very difficult.  But think about the perf problems that even WPF has *with* hardware acceleration.  I'm affraid that the entire methodology for building WPF apps (huge visual trees) presupposes hardware acceleration.  I'm not sure how well this will translate to SL without hardware acceleration.  Time will tell.  I just hope that every SL app doesn't end up being to clunky to use.  As an example, try going here: www.corrina_b.members.winisp.net/.../Testpage.html

and scroll through the data grid.  It's a little klunky on my machine...

Oran wrote re: There's some darkness in your silver light.
on 03-13-2008 1:06 PM

I believe Moonlight does hardware acceleration.  If Linux starts to be the most performant platform for running Silverlight, I'll bet Microsoft will invest the necessary resources to at least do hardware acceleration on Windows.  I'm guessing Microsoft will get there, they're just following the principle of "ship first, optimize later" which I fully support in this case.

One more Flash feature to add to the Silverlight wish list is webcam video support.

I believe the serious issues you describe are a symptom of WPF (a "desktop classic" technology) getting the big red reset button and "owned" in the form of Silverlight by anti-desktop folks like ScottGu.  There's an attempt being made to hand-wave this bias away by doing demo-quality SL->WPF upgrades that "just work," so thanks for bringing to light the issues with this.  It really feels like they're cannibalizing WPF (the Strangler App design pattern), and developers 5 years from now will go "What's WPF? and the old guys will say 'It was that over-engineered speed-bump between WinForms and Silverlight.'"

Unterschiede zwischen WPF und Silverlight 2 | Code-Inside Blog wrote Unterschiede zwischen WPF und Silverlight 2 | Code-Inside Blog
on 03-13-2008 3:20 PM

Pingback from  Unterschiede zwischen WPF und Silverlight 2 | Code-Inside Blog

A.N.Onymous wrote re: There's some darkness in your silver light.
on 03-13-2008 3:31 PM

You've been coding WPF for 4 years, since early 2004? .NET 2.0 was only released in November 2005.

On another note, SL 2.0 Beta 1 was only released at MIX because everybody was expecting new bits. Take it from me that the next beta will be MASSIVELY different.

Marlon Grech wrote re: There's some darkness in your silver light.
on 03-13-2008 3:39 PM


First of all great post!

I think that Silverlight is still a baby and just like a baby, Silverlight is learning from the big brother(maybe sister) WPF. So I am 100% sure that sytles/control templates etc will be fixed soon....

What I am a bit curious on is the networking part of silverlight.... It would be cool to have more rich data access....

Anyway great post.... keep it coming!!! :D

Mark wrote re: There's some darkness in your silver light.
on 03-13-2008 3:42 PM

Can someone give me the 20 word skinny on why Silverlight couldn't be made to work with OpenGL? It's cross platform isn't it?

Rob Eisenberg wrote re: There's some darkness in your silver light.
on 03-13-2008 3:44 PM

@ A.N.Onymous

True.  I started working with WPF before .NET 2.0 was actually released.  The pre-beta was running on a beta of the CLR 2.0.  I actually ended up learning generics, etc by working with WPF ;)

Rob Eisenberg wrote re: There's some darkness in your silver light.
on 03-13-2008 4:48 PM

Crap...looks like Flash is about to one up SL 2.0 in a bad way:



Dew Drop - March 14, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - March 14, 2008 | Alvin Ashcraft's Morning Dew
on 03-14-2008 9:35 AM

Pingback from  Dew Drop - March 14, 2008 | Alvin Ashcraft's Morning Dew

Jose Fajardo (LiquidBoy) wrote re: There's some darkness in your silver light.
on 03-16-2008 5:53 PM

Thanks for that really insightful post, I'm not comming from a WPF background so that was extremely useful.

You mentioned application wide styles not being supported in SL2, unless I miss-read your meaning i believe it actually is supported in the app.xaml file. If you put your style in the app.resources then it can be used anywhere in the application domain.

As for the skinning model in silverlight (called the parts model) I really don't know yet whether I like this approach or not. Right now, I've probably built close to 30 skins on a button control and have to admit I'm growing to like the part's model. BUT saying that i haven't had the fortune of playing with WPF and experiencing the triggers collection you talk about. I'll do more investigation on this sooner rather than later.

I also completely agree with you on the inability to change styles dynamically. Static styles are definetely a sore point for me at the moment, thou the work around is forcing the entire RIA to reload  with the new style in mind (hack but works). (I think this is how AOL did it in there mail RIA)

I would also put 3D libraries at the top of my list for features I would want, purely because we are talking about a RIA application and what better way to deliver rich experiences than using 3D.

Looking forward to more lively debate around all this :)

Rob Eisenberg wrote re: There's some darkness in your silver light.
on 03-17-2008 1:08 PM


Of coarse you can always place styles in the app.xaml resources.  However, they must be keyed.  In WPF you can leave off the key and the style will automatically be applied to the TargetType, which is quite handy.  While not having this isn't the biggest deal (I'd much rather them fix the control templates), it is one of many small things that make SL/WPF compatibility an issue.

.NET worker » Blog Archive » Pappala XBAP wrote .NET worker &raquo; Blog Archive &raquo; Pappala XBAP
on 03-17-2008 5:20 PM

Pingback from  .NET worker  &raquo; Blog Archive   &raquo; Pappala XBAP

Ork wrote re: There's some darkness in your silver light.
on 03-17-2008 7:00 PM

Right on, and if ms claims silverlight to be a subset then it should truly be a subset of wpf, with additional libs to support the unique demands of the web envion.. Also, by making it a true-blue subset it will later help them if they want to make it avaliable as an offline app - quasi air..

Ammon wrote re: There's some darkness in your silver light.
on 03-18-2008 1:52 PM

Wow.  Thanks for the heads up!  I am currently designing a new web application based on Silverlight.  Good to know these things before jumping in to far!

Scott C wrote re: There's some darkness in your silver light.
on 03-19-2008 12:35 PM

Great write up Rob, not working with Silverlight or .Net much lately since I'm now working in a LAMP shop. It's nice to be able to stay on top of Silverlight's development with posts like these. Very constructive. Well, except for the "Poo" references. LOL.  :)

Take care.

notstatic.com wrote notstatic.com
on 03-24-2008 2:39 PM

Pingback from  notstatic.com

Ask Dr. WPF wrote The BIG Problem with Silverlight's Control Templating Model
on 03-24-2008 9:48 PM

Robby has just fired this shot in The Great Templating War Debate of 2008. I don't often disagree with Robby on platform issues, but... I am now compelled to reply with an opposing viewp ...

Neil Mosafi wrote re: There's some darkness in your silver light.
on 03-25-2008 7:39 AM

I really hope these WPF features will make their way into Silverlight.  I am sure MS want the developer/designer experience to be the same on both platforms!  Saying that, the more of WPF that goes into Silverlight, the larger and larger it becomes, so there is the obvious tradeoff here - they don't want people to have to download a 50MB plugin just to use Silverilght!

You mention default styles not working in SL - this is done by the XAML automatically setting the key to the target type if no key is specified.  So have you tried in SL doing <Style TargetType="Button" x:Key="{x:Type Button}">?  That might work, I've not tried yet?

For me a major difference between SL/WPF seems to be in the DependencyProperty implementation.  There is no property metadata, hence (for one thing) you can't have default values.  In WPF you set the DefaultStyleKey property of the control to the type of the Control, which allows the style to be picked up.  Is there any DefaultStyleKey in Silverlight UIElements?

Catching up from -30C. Blew, CHESS, .NET Framework Treemap’s and More « Tales from a Trading Desk wrote Catching up from -30C. Blew, CHESS, .NET Framework Treemap&#8217;s and More &laquo; Tales from a Trading Desk
on 03-25-2008 6:58 PM

Pingback from  Catching up from -30C. Blew, CHESS, .NET Framework Treemap&#8217;s and More &laquo; Tales from a Trading Desk

Lynn Marentette wrote re: There's some darkness in your silver light.
on 03-25-2008 9:47 PM

Thanks for the information and discussion.

.NET & Funky Fresh wrote Silverlight Problems That Affect Me
on 07-26-2008 7:04 PM

I&#39;ve blogged previously about inconsistencies between SL 2 Beta 1 and WPF. In my previous post I

Ezequiel Jadib’s Blog » Silverlight & Composite Application Guidance (Prism): Spike published wrote Ezequiel Jadib&#8217;s Blog &raquo; Silverlight &amp; Composite Application Guidance (Prism): Spike published
on 08-06-2008 2:49 PM

Pingback from  Ezequiel Jadib&#8217;s Blog &raquo; Silverlight &amp; Composite Application Guidance (Prism): Spike published

Ezequiel Jadib wrote Silverlight & Composite Application Guidance (Prism): Spike published
on 08-06-2008 3:10 PM

Weeks ago we shipped the Composite Application Guidance for WPF and with the Prism team we started to

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)