So now that the project is launched, I'm feeling reflective. And I have to say: Silverlight is a worthy competitor to Flash. It is a lot of fun to build in. I recommend it. I think there are times when it'll be faster to build certain things in Silverlight than Flash and vice versa, and it is a matter of learning where the strengths and weaknesses are for each.
There were some things that frustrated me, but overall I found Visual Studio to be a great environment to learn to code in, C# was an extremely easy language to learn and most importantly of all the Silverlight player to be really flexible to the stress we put it under. Our team noted several times that we especially like Silverlight's animation capabilities -- we felt like we had far more "control" over what was happening on the screen than in Flash.
Here are some general observations and got yas that I bumped into:
Timeline animation is different.
Not better or worse, just different. Silverlight has you set up your "base" state... where all the objects on the screen are supposed to begin. From there you can create any number of storyboards that animate them around. What's neat is that the storyboards assume you're always animating from where the object is at to where it's going, and it never resets any properties that are changed -- so you can have one storyboard that alphas an object up with another that moves it across the screen, play them both at the same time and it looks like one animation. It takes some getting used to but the result is that animations will never snap, which is neat.
The downside of this is that if you have a simple two state animation -- for example, rollover/rollout -- and you change a property and forget to animate it back to its initial position in the rollout, it doesn't animate correctly. It's complex to explain, but this brand of timeline tweening is really interesting.
Silverlight is the better videoplayer solution
What's that? Did I just say Silverlight is BETTER at video than Flash? Yes. I think the MediaElement control offers everything the FLVPlayback component does, but it's much more responsive. Smooth Streaming is REALLY cool. In Flash there's NetStream, NetConnection, VideoPlayer, FLVPlayback... so many different levels of access, and so confusing if you try to write your own. MediaElement is somewhere between VideoPlayer and FLVPlayback, but just feels much more straightforward.
It is pretty clear that Microsoft really wanted to stress the video capabilities of Silverlight from the get go -- what with the Netflix player, the Olympics, and so on. I was surprised that it did a lot more than just stream video... it seemed to make it easy to program and to build.
XAPs aren't fun to load... but are a blast to explore.
When you create a Silverlight project, you start with a XAML (MS equivalent to MXML) to describe visuals and use C# to map to add functionality. Your finished XAP is compiled from a "solution"... a group of projects you individually create. So in the case of the Victoria's Secret Fashion show we had a couple of projects: com.bigspaceship, com.victoriassecret and then whatever the built in Microsoft libraries were.
XAPs actually are just standard issue ZIPs, like the AIR extension. When you crack one open you can see the assemblies (dll) inside. Interestingly each project gets its own assembly... so we have the com.bigspaceship.dll file inside our final XAP. These can be pulled out and used in Visual Studio projects, which do some small amount of basic code hinting... great for attempting to reverse engineer logic. I learned a lot this way.
Of course, when loading a XAP at runtime this also means you have to programmatically recreate the process -- extract the assembly you need from the XAP, somehow get C# to convert it into a format it understands and then finally apply. This gets pretty tedious pretty quickly and is obviously much more cumbersome than simply loading a SWF and adding to the stage.
It also gets pretty hard to seriously talk about files. Try it: "Hey Joe, I just zipped xap xamls for you. Zug zug."
Classes can get really messy
C# supports real overloading -- even constructors. This is awesome. I love having multiple methods named the same thing automatically doing something different depending on the variables passed. Take this example:
void foo() {} void foo(string name) {}
If you call foo and pass a string, it knows to go to the second method. I like this way more than optional arguments like ActionScript... it feels stricter and I'm virtually certain it's faster performance wise, though I didn't test.
C# also supports partial classes, meaning you can have a class written across multiple files. Your XAML files are actually converted into partial classes, the other half being a corresponding C# (which I believe is called "code under"). This means you can have classes named anything you want, anywhere you want. No folder structure that matches the package name deal. Imagine the mess you can create if you're not careful.
Easy things should be easy. But they aren't.
The Silverlight version of movieclip.x = 100? usercontrol.setValue(Canvas.LeftProperty,100). Why not just make a wrapper for x and y built into the language? Why make it so hard?
Visibility is just as silly. Each object has a visibility property that can be one of two options: Visibility.Visible and Visibility.Collapsed. What's wrong with just true and false?
Incidentally, I tried combining this with some fun namespaces and I wrote this line of code that I am enormously proud of:
visibility.visibility.Visibility.Visible.Visibility = Visibility.Visible;
Traversing the Silverlight layout tree (DOM) isn't much easier. Since everything is strictly typed, if you want to access a property you know exists in a user control from some other scope you have to say:
usercontrol.FindName("button") as Button;
Of course this gets absurd when you have nested User Controls:
((usercontrol.FindName("uc") as UserControl).FindName("nestedUserControl") as UserControl) // and so on.
Linq is a neat take on XML... but E4X is better.
Parsing XML in Silverlight feels a lot like writing a SQL query:
from foo in xmlDocument.Descendants("moop") where(foo.Attribute("id").Value == "apple") select foo;
Compare with:
xmlDocument.moop.(@id == "apple");
E4X is a lot less code to write and a lot easier to read straight through.
Building on OS X is critical.
Apple understood that in order for the iPod to reach its full potential it had to reach out to a market outside of their specific hardware and software. The result was iTunes for PC, which was about as critical to it's success as anything.
Microsoft needs to take the same approach to Silverlight. Whether they like it or not, designers are mostly working on Apple computers these days. If developing for Silverlight is going to require the purchase of a separate operating system or the performance hit of emulating windows, the market for creative professionals choosing it as their platform is exponentionally smaller.
Learning C# and Blend is empowering
I felt like I learned a dozen different languages all at once. I moved straight into Windows EXE development from here... same XAMLs, same C#, slightly more functionality. Yeah I can make full fledged apps in AIR, which is great... but there's just something really rewarding about Objective-C and C# in that feeling that you're making a "real" app. That learning one thing allows you to really build even more.
Obviously there's so much more to discuss... this is just scratching the surface. Silverlight's potential is really exciting to me... I can't wait to build the next project.
For you scripters out there intimidated by a new language, there was a single resource that I found critically helpful: shinedraw.com. Terence Tsang is a developer who executes simple tasks in both Flash and Silverlight, then posts the source code for each on his blog. There's no easier way to learn than to look at how he loaded a file in AS3 and the equivalent in C#.
