Server-side generation of the user interface
One of the most interesting aspects of Silverlight is that the user interface is typically created using eXtensible Application Markup Language (XAML), which is then pulled down by the control and rendered to the user. Clearly, this UI need not be static, but can instead be dynamically generated based on user input in combination with data and security information held on the server.
At this point you might well be thinking “So what does this offer me over existing ASP.NET or ASP.NET AJAX solutions?” Well, the main benefit of Silverlight is its support for features such as overlaid video, flexible 2D vector graphics and powerful animations and transformations, all of which would be complex to achieve in a pure ASP.NET AJAX environment. The fact that this UI can additionally be generated dynamically following a similar model to the other technologies does tend to make Silverlight compelling in many scenarios.
Client-side interactivity
The Silverlight control exposes its internal XAML DOM to the browser, enabling you to write client-side JavaScript that adapts and changes the UI, and which responds to the events that are raised from the XAML-based elements. Thus you can write client-side script that calls back to the server to obtain new UI content, much as you would do with a standard AJAX application. This familiar programming model will make Silverlight very accessible to the myriad of current Web developers that exist today, allowing you to complement and reuse existing frameworks and services, rather than totally replace them.
However, there’s an even more interesting story behind Silverlight and the client: the presence of managed code on the client. Whilst not available in Silverlight 1.0, it’s so significant a development that it needs to be briefly mentioned now.
Is that a CLR I can see on the client?
At the time of writing (late-June 2007) there were two announced versions of Silverlight: 1.0 and 1.1. Interestingly, 1.0 is in beta and has the benefit of a “go live” licence, whereas 1.1 is an early alpha release.
It might sound a little strange that version 1.1 is in alpha before 1.0 has even shipped, but when you take a look at what the two versions can do it makes some sense. Figure 3 provides a high-level overview of the types of applications that you can write with the different versions.
Figure 3: Silverlight and managed code
In Silverlight 1.0, you can create applications that have a XAML user interface, but all of the event handling code has to be written with JavaScript. With version 1.1, however, you gain the ability to write managed code on the client, using languages such as C#, Visual Basic and IronPython. This is because the version 1.1 plug-in contains a lightweight version of the CLR and .NET Framework, which includes support for features such as LINQ, multi-threading, JSON-based Web Service calls, generic types and collections, isolated storage and regular expression processing, amongst others.
Version 1.1 also supports a managed bridge to HTML, allowing developers to manipulate the HTML DOM through managed code. This yields the intriguing possibility that developers will start writing HTML-based, ASP.NET applications which use no XAML on the client, but which have client-side C# or Visual Basic event handling and web service calls! Clearly, this will represent a significant win for developers with strong .NET skills that are weaker on client-side programming, as they can leverage their existing skills to write richer client-side applications. They also gain the benefits of stronger type verification and better performance over a purely script-driven application.
Of course, you’ll be trading some reach to gain these features; but given that the combination of Windows + IE/FireFox and Mac + FireFox/Safari accounts for well in excess of 90% of the browsing marketplace, you might well feel that this is a risk that you’re prepared to take, especially as there is also an open source port of Silverlight in development, known as Moonlight, which is targeted at Linux and Unix.
Rest assured that we’ll be taking a detailed look at the capabilities of Silverlight 1.1 in a later article.
Choosing a presentation stack
Silverlight offers developers an increased choice when deciding upon a presentation stack for their applications, and Figure 4 highlights where it fits in the range of choices.
Figure 4: Performance/features v. reach
Windows Forms is omitted from the figure, but it would lie adjacent to, albeit slight below, the corresponding WPF choices. It should also be noted that there is no difference in reach capabilities for the two Silverlight choices; it’s just that the .NET applications with a managed CLR on the client offer greater power.
It’s worth noting that whilst Silverlight has richer graphical and media capabilities than ASP.NET, it is by no means a replacement for existing ASP.NET and AJAX applications. For example, ASP.NET excels at form-based Web applications whereas Silverlight 1.0 has no input controls of its own whatsoever. It is thus reasonable to expect that Silverlight will be used to complement and enhance existing applications, rather than as a replacement for them. The true “sweet spot” for Silverlight definitely lays in the development of rich media, interactive mini-game or graphical data presentation applications where you need a level of reach that goes beyond that available to full WPF.
Alternative visions of the future
Of course, when discussing presentation stacks it’s important not to overlook alternatives such as Adobe Flash, especially when combined with Adobe Flex; Java and JavaFX; and the newly announced Adobe AIR (formerly code-named Apollo), which promises a run-time that supports online and offline applications on the client. Whilst it’s impossible (and foolish) to predict which of these technologies will achieve pre-eminence, the sheer number of competing technologies clearly indicates that the drive to create ever richer Internet-based applications has motivated the main vendors to expand their and our horizons far beyond the traditional limits of the browser.
Building a Silverlight application
To begin with, you’ll need some tools. At a minimum, you should have Visual Studio 2005 and the Silverlight 1.0 beta SDK installed, the latter of which can be downloaded. The SDK contains samples, documentation and a template that you can use in Visual Studio 2005 to facilitate the creation of Silverlight applications. You can also use Visual Studio 2008 (aka “Orcas”) if you prefer, with the Silverlight 1.1 alpha SDK. Note that Visual Studio 2008 is a requirement for writing Silverlight 1.1 applications. You will also need some decent design tools; otherwise you’ll find yourself designing your application using a text editor as the visual design tools inside Visual Studio are somewhat limited. Your toolset should include Microsoft Expression Blend 2 (shown in Figure 5) and either Microsoft Expression Design or Adobe Illustrator. If you go for the latter you will need Mike Swanson’s XAML Exporter plug-in.
Figure 5: Expression Blend 2 in action
Expression Blend 2 is used to create the project itself and the XAML scenes; Expression Design/Illustrator is typically used to create the smaller assets, such as the various buttons on the media player in Figure 1. Developers will definitely need to become familiar with the Expression products, even though they are targeted at designers. Fortunately, Blend 2 and Visual Studio share a common project file format, which means that you can flip back and forth between the tools without loss of fidelity or data.
Comments