Silverlight Development May Be Frustrating for WPF Programmers

During the last year I have (intermittently) worked on about ten WPF-based solutions (applications or component libraries). I admit, at first, it was not easy at all to learn WPF and to get to a point where WPF to seem easy to use. But after around 3 months of learning and doing WPF practice I felt that all this effort has been rewarded even more than I initially expected: using WPF is NOT just for fancy user interfaces for applications, but it is a great way to develop enterprise applications too, in an elegant, easy, and very expressive way (for example using facade objects that link to the underlying business or data objects using the same binding mechanism as inside the UI, and many other advanced features).

The best features from WPF are well known and discussed: XAML with code behind, resource dictionaries, styles, templates, dependency objects and properties, bindings and converters, etc. Everything is absolutely great when these two conditions are both true: (a) you have learned WPF so that you are experienced with it, and (b) you are building a WPF application (either Windows-based or browser-based, i.e. XBAP).

The frustration comes only when an experienced WPF programmer wants to build a Silverlight 2.0 application. (Silverlight 1.0 is simply not for developers, in my opinion, so I don’t even go there.) As Silverlight 2.0 uses only a subset of the WPF and .NET infrastructure (understandable, as it is meant to be this way, to be able to perform on multiple platforms, be very easy to install as a simple add-on for browsers, etc.) when a WPF programmer wants to actually develop real-world Silverlight 2.0 applications (and not just toys) the problems appear:

  • no elegant way to do merging for resource dictionaries (the workarounds are ugly), and therefore no elegant way to do themes (except using Silverlight toolkit which is somehow good but only for themes not for other, more general, types of resources);
  • no elegant way to do property changed handling, value coercion handling, and value validation for dependency properties;
  • bindings to a custom DependencyObject-based class do not care about property changed events, you need to use INotifyPropertyChanged to make bindings work (at least that works!); and DataContext does not work at all if the data object to set is an anonymous type (new { P1 = …, P2 =… });
  • localization is hard to implement and requires very advanced skills;
  • although there are some new controls (not available in WPF, such as DataGrid, or DatePicker), some well known controls from WPF (such as ListView) are missing or have different behavior (see this for some examples, but notice that some of the problems referred to there are resolved in the final Silverlight 2.0 build).

Others seem to have similar thoughts. If you have some spare time or if you are just about taking a Silverlight job (after you beaome a WPF programmer), read these and think twice:

About Sorin Dolha

My passion is software development, but I also like physics.
This entry was posted in Computers and Internet. Bookmark the permalink.

Add a reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s