Microsoft's answer to Adobe Flash and Flex and several other RIA (rich Internet application) and AJAX frameworks, Silverlight arrived with a flourish just over one year ago. Silverlight 1.0 (see my October 2007 review) manipulated its multimedia-savvy, WPF (Windows Presentation Foundation) user interface using JavaScript. Silverlight 1.1, which added support for compiled .Net languages and supported more of the .Net API, was available at that time only as an alpha test.

Silverlight 1.1 turned out to be such an important upgrade for Microsoft that it was eventually renumbered Silverlight 2. As delivered now, Silverlight 2 supports all .Net languages, including the dynamic languages such as IronPython and IronRuby, and it contains a good chunk of the .Net base classes, including newer features such as LINQ (language-integrated query). In addition to a rich set of controls with more on the way, it has APIs for an alphabet soup of networking, including REST, SOAP, RSS, and HTTP; includes local data caching and storage; and supports HD video among other rich media formats. H.264 video and AAC (Advanced Audio Coding) audio support is planned for Silverlight 3.

Poster-child Silverlight deployments such as the Beijing Olympics last August have been favorably reviewed and generally well received. There was of course the usual chorus from people with incompatible hardware and operating systems, but nothing unexpected. From Microsoft's viewpoint, at least, the Silverlight Internet video streaming of the Olympics provided by NBC in the U.S. China Central Television in China, and broadcasters in 10 other major national markets, was a huge success. More recently, Silverlight 2 enabled Blockbuster to offer high-quality streaming video to PC and Mac users of its MovieLink service.

Capabilities and controls

Silverlight 2 should eventually be good for any kind of RIA, given its strong language support and class library and good runtime performance, not just video streaming. Right now, it probably lacks a few user interface controls out of the box for some applications: There are only 28 items in the standard Silverlight Controls toolbox, and another 12 in the Silverlight Toolkit, with a plan for 100 controls total to be made available over the next months. It's not that hard to build new Silverlight controls, and many are already available from ISVs, but if you're not in a hurry, you may find that Microsoft eventually delivers all the controls you need.

Security in the face of cross-domain access is a potential issue for any browser-based application, whether or not it uses a plug-in such as Silverlight or Flash. Silverlight does have its own cross-domain security mechanism, controlled by a manifest file setting, which defaults to the most secure setting.

I have seen accusations online that the Silverlight local data storage might still be vulnerable to cross-domain attacks despite this mechanism, but I haven't been able to prove or disprove this. The same source claims that Flash local objects are open to the same kind of attack.

Development and design

I tried Silverlight 2 development using Visual Studio 2008 SP1 and Expression Blend 2 SP1. I didn't have any trouble picking it up and developing with it, but I was already familiar with Visual Studio, C#, the .Net Framework, and XAML. Other programmers with backgrounds in .Net languages (now quite a large selection, including IronPython and IronRuby in addition to C#, Visual Basic .Net, JavaScript, and so on) and with XML-based markup (including MXML and even HTML) should find it easy to learn and develop for Silverlight.

The basic method for programming XAML elements is to give them a x:Name tag, for example:

<TextBlock x:Name="message1" Text="Message:"> </TextBlock>

Once the x:Name attribute has been set, the program can manipulate the properties of the element, very much in the same spirit as JavaScript manipulating HTML elements in DHTML:

message1.Text = "Hello, " + name1.Text;

This connection between program and XAML element by name is the key to using teams of programmers and designers to develop Silverlight and WPF applications. As long as the names don't change, the programmers can modify the code-behind files, and the designers can modify the XAML files without breaking the interface between the two. They might not even use the same tools.