For a WPF developer, crossing over to Silverlight development can be a pretty mindboggling adventure.
I mean - if you’re currently engaged with Windows Forms or ASP.NET and seeking new advancements, Silverlight would (should?) be a logical step forward in your life as a developer. There are, of course, a whole variety of new concepts and patterns to be learned, but compared to WPF, Silverlight is really not that big. When comparing Silverlight and WPF, I often describe WPF as Silverlight’s older brother: calm, capable & wise business man, dressed in a grey suit. On the other hand, Silverlight would be a very agile, very smart and witty teenager, popular among the crowd, although sometimes crossing the boundaries of what’s considered a good behavior. But at the same time he would be pushing the tolerance limits of his older brother, teaching him some new things and giving him a different, fresh perspective on life.
How so?
WPF is pretty big, framework-wise. Silverlight is substantially smaller, but:
a] Silverlight had Visual State Manager in v2. WPF VSM was announced only after Silverlight was out and is in the making, as of now. VSM was introduced to replace styling with the support of triggers, which don’t really exist in Silverlight (there’s the EventTrigger, but that’s pretty much it).
b] Silverlight had a DataGrid in v2. WPF DataGrid v1 has just been released.
c] Silverlight additionally allows some simpler Xaml constructs, like TargetTyping to a type name (TargetType=”Button”) rather than a type reference (WPF: TargetType=”{x:Type Button}”), etc. WPF is going to follow Silverlight on this too.
Silverlight clearly took the lead with introducing new features into the framework and improving what was considered as not so good in WPF. And with Silverlight v2 being RTW for only a few months now, we’re expecting some big announcements on MIX09about v3 , which is said to be released later this year. Silverlight is maturing fast.
Of course, there are currently some crucial things missing in Silverlight that ruins the experience with developing a decent (LOB) application:
a] No commanding support.
b] No real business objects validation support.
c] etc, etc… The web is full of Silverlight missing features. Google it. I’ll only post two MSDN links on differences between WPF and Silverlight: here, here.
If you’ve learned (and practiced) WPF prior to Silverlight, those differences could easily turn out to be a wall, which you’re going to hit into when actively engaged in developing a real-world Silverlight project. Take, for example, the DependencyObject. The guy who posted this question obviously studied the wrong documentation when learning Silverlight. And it’s so easy to take a wrong turn when navigating through the links describing Silverlight classes and functionality. One wrong click and you may be directed to the WPF-version of the page, describing DependencyObject, for example. Not knowing that you’re really studying the WPF implementation (which differs significantly from what’s in Silverlight) you read all about it; and you learn it wrong! I myself didn’t know about this difference until the mentioned post got me to start Reflecting on both versions of DependencyObject.
Here’s the short story: if you declare a DependencyProperty on the DependencyObject in WPF, any change to the value of this property will raise the PropertyChanged event, without the need to implement the INotifyPropertyChanged interface. In Silverlight, this is no go. Silverlight’s DependencyObject doesn’t implement the OnPropertyChanged method like WPF DO does, so you have to implement INotifyPropertyChanged interface on your object for it to properly propagate PropertyChanged event to its listeners. There is, however, a reasoning behind this: Silverlight’s Binding construct doesn’t support the ElementName property, which allows binding to some other control on the same page. All controls are descendants of a DependencyObject so therefore, if bound to, they should notify their listeners if one of dependency properties has changed. But because you can’t bind to those controls, there is no need for DependencyObjects to support PropertyChanged notification on dependency properties. You commonly bind your controls to business objects in Silverlight anyway, and putting DependencyProperties into business objects is not recommended even in WPF. Business objects should implement INotifyPropertyChanged-enabled properties, be that in Silverlight or WPF.
All those tiny little differences don’t make it easy for someone concurrently involved with Silverlight and WPF projects. Imagine working on two simultaneous projects, but one in C# and the other in VB. The syntax differences of those two can be easily compared to differences between Silverlight and WPF. Constantly switching between two similar mindsets can be a pain.
We’ve all been told several times that Silverlight is a subset of WPF. Well, rather than a subset, I like to call Silverlight a REset of WPF. I mean, with Silverlight, Microsoft now has this great opportunity to gradually create a fresh, true cross-platform, “runs-everywhere” presentation framework from the ground up, being able to cover all kinds of applications imagined, from games to business; the latter of course greatly powered by the web (services / cloud). They’ve learned what works and what not from working on WPF, so Silverlight would get only those bits that do work. At the same time WPF will continue to improve together with Silverlight, until… until Silverlight grows powerful enough to forget all about WPF :) Might be far-fetched, but hey…
So, will WPF eventually die? Is it a dead end? When?
Let me answer this question with another answer: is Windows Forms dead yet?
On the other hand, look what we’ve been programming about 10-15 years ago… looking 15 years in the future, I’m afraid there will be neither Silverlight nor WPF, but something uber-both. So whatever solves your current business problem, goes.
Subscribe