When first looking into the possibilities for using
Silverlight with SharePoint, I found a number of things confusing, so in case anyone else out there is starting from scratch like I was, here is what I learned. Hopefully most of it is correct :)
a) Silverlight vs. Flash - yes, on a number of levels Silverlight is just a MS version of Flash. A great example of this, and of a cool tool, is the
GOA framework for building/porting windows forms applications to run on Silverlight. The same tool will create Flash versions also. The big difference is really the development environment and media support are all tailored to MS technologies such as (.NET, XAML, WMV, etc.) - more on this in a second. I think MS is rightly distancing itself from Flash, not just to avoid a me-to comparison, but I think the positioning Flash has currently in the minds of many people really sucks. People think of "flashy" things on a web site that are generally graphical in nature and also generally useless when they think of Flash. Silverlight can start with a clean slate as rich internet application platform and become something completely different, even if in fact it is fairly close to Flash in terms of capabilities when it comes to RIA's.
b) 1.0 Beta vs. 1.1 Alpha - now this was really confusing at first. Basically Silverlight 1.0 gives you the ability to do rich media, etc. but must be scripted using JavaScript. So basically a Silverlight 1.0 "application" is a combination of XAML and JavaScript. Silverlight 1.1 allows you to write the logic for the control in .NET instead of JavaScript and the Silverlight loads the dll and runs it. This has several
benefits such as being easier for developers who are familiar with C# but don't know much about JavaScript. It also eliminates the cross-browser issues that arise due to differences in the JavaScript engine in the browser. Finally, in some cases the Silverlight .NET mini-framework is
faster than JavaScript.
c) SharePoint deployment - It looks like if you go with Silverlight 1.0 + javascript, you should be fine with deploying this in a simple .dwp web part (e.g. by using a content editor web part initially and then exporting it). However, if you go for Silverlight 1.1 using .NET and a .dll, you can't just upload the .dll to a document library, so you'll need to configure things
differently. Also, here is an example of a SharePoint Silverlight
web part template I ran across - haven't tried it.
d) XAML? - Silverlight UI is based on XAML. While this is the basis for WPF in .NET 3.0 that ships with Vista and is available for XP also, it appears that there are very few developers (e.g. doing a search on a popular development job board like
RentaCoder yields only a handful of hits for XAML, and only two for Silverlight) who know how to build XAML applications using tools like
Expression Blend 2 (you'll need 2 for Silverlight support). XAML is likely the way of the future, but for right now there isn't much happening on the developer side. My suspicion is most developers will end up using UI toolkits from folks like
Telerik and
Infragistics to abstract themselves completely from needing to know any XAML at all initially, and slowly it will gain adoption.
Ok, it's cool, but what is it really good for when it comes to SharePoint? The obvious application is rich media. If you're going to have WMA or WMV content on your SharePoint site/portal, Silverlight is a great way to render it in a YouTube style fashion. The fact that you can go full screen with the Silverlight control is just a killer feature in my mind, especially when you're talking about screencast content that MUST be viewed full-screen for any decent quality. Stay tuned to see something like this coming to my blog in the near future.
Beyond that, the next area I can see being interesting is running client-side computationally intensive data visualization tools. My guess is you'll see something from the experts on this at
Dundas soon.