.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


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)