Silverlight: The good, the bad and the ugly
I wasn’t sure if I would blog about this or not because it’s likely to cause some commotion, but I decided to do it anyway. This post is not meant to talk down on Silverlight. I just finished a 3-day hands-on, in-depth Silverlight course and wanted to share what I learned about Silverlight coming from a Flash/Flex background. I am sure some of you may encounter the same things when you learn about Silverlight.
The good
There are a couple of things I really like about Silverlight — things that are currently missing or not obvious with the Flash platform.
The first thing I really like is the concept of threading. Being able to spawn off “complex” tasks without choking the main thread is pretty cool. You could, for example, show a really smooth animation when you are loading a bunch of data in a separate thread. This can also complicate things though. You’ll have to manage those threads more or less yourself and may get into trouble not being able to oversee what the application is doing. Also, with something like LiveCycle Data Services you can load in large amounts of data really fast in a binary format that you don’t need to parse, which can eliminate one of the main reasons you would need threading. I’m sure some of you could think of 101 different ways to use threading though and that’s also why I said I really like the concept of threading in Silverlight.
I also like that a Silverlight application can directly communicate with the HTML document it is hosted on by simply setting a parameter. This allows you to get to the HTML DOM and JavaScript on the page, and enables very easy integration with AJAX.
Being able to code in either C# or VB.NET is also a great feature. Especially since these two languages are pretty familiar to people developing for the Windows platform. I’m not one of them but I found that C# is similar to ActionScript. Next to those languages you also have XAML which does more or less the same things as MXML. The basic concept is exactly the same but some seemingly simple tasks have been made very complex. And that brings me to “the bad”.
The bad
Code in XAML and C# is really verbose. The project we worked on during the training can be done in Flex with half the code. I intend to remake that same project in Flex just to show the difference. Like I said earlier, some seemingly simple tasks are unnecessarily verbose in Silverlight. Animating the rotation of an object is a good example. Because Silverlight objects don’t have a direct rotation property, the only way of doing this is by setting up a RenderTransform property.
So for Silverlight:
<Button>
<Button.RenderTransform>
<RotateTransform Angle="45"/>
</Button.RenderTransform>
</Button>
For Flex:
<Button rotation="45"/>
Data binding is also another good example. In Flex you can bind to a variable or object by using {}. This is exactly the same with in Silverlight but you also have to add the Binding keyword to the curly brackets even though curly brackets already mean that you are data binding. Some things are also inconsistent. Naming a control for instance can be done with the Name keyword but also with x:Name. Even the Expression apps are inconsistent with the code they deliver.
Styling controls is an absolute nightmare! I honestly think that this is going to be Silverlight’s Achilles’ heel! Let me explain… I can’t even count how many times people told me how good the designer/developer workflow is when creating Silverlight apps. That may be true when you only use the Expression tools to actually create your design… well… partially. Even though this is said to be roundtrip editing, it really isn’t (though at this time the Expression tools are still in beta). You’re supposed to be able to create a design in Expression Design, do little animations in Expression Blend, and code it all together with Visual Studio. If you keep that order, it’s all OK but as soon as you start adding code in Visual Studio and want to go back to Expression Design you are in trouble. More than once, the instructor had to comment out code in Visual Studio before actually being able to open it back up in Expression Design or Blend.
But let’s be honest. It’s a fact that designers work with tools such as Photoshop, Illustrator, and Fireworks and they’re not going to use the Expression tools any time soon. So adding standard design tools to the workflow is a must. To some extent, it is possible to import artwork from Photoshop or Illustrator in to Expression Design but that’s about it. Expression Design then “transforms” the artwork to XAML. In Expression Blend, you can then add states, transitions, and simple animations. This XAML can then be handed over to the Visual Studio developer. While with HTML and Flex it’s possible to separate design from content, in Silverlight this is not very obvious. There’s no CSS support, but you can make styles with “Resources”, which are similar to CSS but are pure XAML. Why Microsoft didn’t choose to have CSS support and decided to re-invent the wheel is unclear to me. Another thing that really annoys me about these Style Resources is that they’re not automatically applied. Say you’re making a style for a button. With CSS that means that all buttons automatically inherit that style but with the XAML Resources, you actually have to tell every single button that that style applies to it. And since these Style Resources are XAML code, you can use only one application to edit these Styles: Expression Blend.
Another thing that I really couldn’t grasp is the lack of HTML tag support in text fields. But there is a <Run> tag (which is basically a font tag) to set font colors and so on. Again… Why? There’s also no way of getting text styled with CSS files like you can with Flash/Flex.
The set of controls available in Silverlight is also limited. There’s no ProgressBar, ComboBox, or charting. The text field control also doesn’t have password support. But to be fair, Silverlight 2 is still in beta and we were told that Microsoft will be adding another six controls to the framework. We were told that MS keeps the number of controls to a strict minimum so that 3rd party developers can create and sell extra components. This brings me to another thing I need to point out. A Silverlight application is “compiled” as a XAP file, which is nothing more than a ZIP file. When you buy a component from 3rd party developer and add that to your application, then this component is completely exposed in your XAP file. It’s not obfuscated or encrypted. Anyone can open up that XAP-file and use that component that you paid for. Sure, you can also open up a SWF file but it’s a lot harder to get a component out of a SWF than it is to get it out of a XAP file.
The ugly
I know the Expression tools are still in beta but it has to be said that all the tools (including Visual Studio which is no longer in beta) felt extremely buggy and incomplete. We saw crashes and error screens more than once.
Over these three days, I got a strong feeling that Silverlight was created by people who don’t know anything about designers. My gut feeling is telling me they should just bin the Expression Studio and start all over again but this time hire some people with design experience — and they should probably hire people with Flash/Flex experience (even though it’s already so similar to Flex). These three days have really opened my eyes. It’s not as good as I imagined it (especially after all the hype and beta cycles) and I don’t see it getting much better before final release.
Switched to WordPress
I never thought the day would come that I traded in my fancy Flex front end for a more conventional blog front end but sadly today is that day. Well… First of all, it’s mainly because I am too lazy to actually complete all the plans I had for the Flex front end. Things like video embed, better HTML support, code hinting, … the sorts of things that are standard in just about any blog engine out there.
I’m pretty sure I will eventually go back to a Flex front end but for now, this will do just fine. I plan on blogging a lot more including stuff like code samples, how-to videos etc…
I would also like to apologize if this move to WordPress totally hi-jacked your newsreader or feed-aggregator. I added a permanent redirect from the old rss-url to the new one so that may cause a complete refresh of my items. I hope not, but it could happen. And if it did, I apologize.
Also, if you came here from a Google search result, chances are this page was not what you were looking for. I only converted my last 10 articles from my previous blog to the new blog so I’m sorry if the article you were looking for is no longer here.
Feel free to follow me on: 
