10 Things You Should Know About Microsoft's Silverlight

Software developers are busy kicking the tires on Silverlight, Microsoft's answer to Adobe's Flash. This summary of not-necessarily-technical information will help IT managers identify what's important about the new technology.

Crafting a Web strategy is important for any thriving business. However, implementing that strategy with rich Internet applications (RIA) is not always as easy as it should be. To ease that pain, Microsoft recently announced Silverlight, a cross-platform, cross-browser plug-in for Web application developers. The plug-in, currently available as a "Release Candidate" (which for all intents and purposes means it's released now), enables rich application development including media, interactivity and animation. The Silverlight plug-in currently works with Internet Explorer and Firefox Web browsers on Windows and with Firefox and Safari on Mac OS X.

I've been using Silverlight since I taught a course for internal Microsoft developers, shortly before the software's public unveiling as "WPF/E." I've written several books about Microsoft-based software development (such as Pragmatic ADO.NET [Addison-Wesley]), I co-wrote four Microsoft developer certification books, and I have invested quite a bit of time in examining the promises that the company is making for this "Flash killer." It's always hard to be critical of software that isn't fully released yet (for one thing, it's impossible to point out serious bugs since they may be addressed by the time you fire up the development tool), but the following reflects my professional and technical judgment based on several months of hands-on experience.

With the public release of Silverlight imminent, now is the right time to become familiar with Silverlight and how it might impact your Web application strategy. With so much Silverlight information available right now, it is difficult to distill what is important and what is hype. I'll do my best to lift the fog with these 10 things that you should know about Microsoft's Silverlight.

RELATED ARTICLES

Microsoft Adds Open-Source Twist to Silverlight

ABC: An Introduction to Web 2.0

Why Ruby on Rails Succeeded

Sign up for the Development & Architecture Newsletter

1. Silverlight Avoids Cross-Browser/OS Issues

For most development teams, developing a website that will work identically with the popular browsers of the day (including Internet Explorer, Firefox, Safari and Opera) is a difficult proposition. The problem is not simply the necessity for multiple code implementations but also exponentially large testing sets. As a developer creates matrices of browser versions and operating systems, the number of test beds needed becomes enormous.

Usually there are two ways that a development project addresses this: support only a small subset of Web browsers, or increase the number of quality assurance personnel.

In contrast, the Silverlight plug-in enables an identical development model regardless of user operating system and browser. Currently, two operating systems and three browsers are supported. Microsoft is promising to add support for the Opera browser on Windows and Mac. In addition, the Mono project has made tremendous strides in its Moonlight project, which intends to bring Silverlight to the Linux platform.

2. Silverlight 1.1 Is the Real Story

The recent Release Candidate of Silverlight 1.0 has many organizations considering whether they should start working with Silverlight. While Silverlight 1.0 has many important and interesting features, in reality most Silverlight adoption hangs on its anticipated 1.1 release.

The Silverlight 1.1 release (currently in an Alpha preview) is the first to support .NET in any appreciable way. This includes the basic .NET languages, C# and Visual Basic. In addition, according to Microsoft, Silverlight 1.1 will have .NET support for dynamic languages, such as Ruby, Python, dynamic Visual Basic and managed JScript. In my opinion, the important languages for Silverlight to support are C# and Visual Basic, as they allow current .NET developers to create interesting Silverlight applications. In the Silverlight 1.1 release, any .NET language should be supported, since what is actually delivered to the browser are .NET assemblies.

In contrast, Silverlight 1.0 only supports ECMA languages that are interpreted in the client. Silverlight 1.0 works well for existing Web developers who are already using client-side script for their work.

Silverlight 1.1 also supports a rich custom control model, which is important to ensure an integrated development experience. The Silverlight 1.0 experience is much less mature and is unlikely to get third parties interested in control development.

3. Silverlight Uses Technologies Your Developers Already Know

Silverlight is built with existing Microsoft technologies: a mix of Windows Presentation Framework-like XAML (XML application markup language), JavaScript and .NET technologies. If your developers are already familiar with Microsoft .NET and Web technologies, they can use their existing knowledge to build Silverlight applications. Even if your developers lack these skills, learning these technologies has applicability beyond the single product or project—which isn't necessarily the case for other solutions, such as Adobe Flash's ActionScript.

The version of Silverlight you choose to introduce to a new project will likely depend on your development team's skill set. If your development team primarily does heavy ASP.NET server-side development (mostly C# and VB.NET), you should wait until Silverlight 1.1 is available. If your team is adept at client-side languages like JavaScript, Silverlight 1.0 is a great platform to introduce.

4. Silverlight UI Is just Markup...Like HTML

XAML is the Silverlight's Lingua Franca for user interface design. You may already be familiar with another popular markup language, HTML. HTML files are plain text that contain information that tells the Web browser how to render the look and feel of a webpage. XAML does the same thing. However, instead of the browser interpreting the instructions about how to render the file, the Silverlight runtime does the rendering.

XAML being markup is important because it can be created dynamically. No matter what tools your developers use for server-side Web development, you are probably creating dynamic HTML to create pages. This technique is so compelling because you can create reusable pieces of HTML that you use on your site. A good example is the design of the main page of most websites. Normally, the header and footer (and often the left and right side borders) are reused throughout a webpage.

Because XAML is just markup, you can use server-side technologies to dynamically create XAML, just as your development teams already do with HTML. The markup language is different, but the techniques are the same.

5. Silverlight and Ajax Technologies Are Complementary

The Web is evolving. When the Web was new, back in the 1990s, everyone warned that developers should move as much as possible to the server so the application could scale. While this works well technically, it hampered the user experience. Now Ajax is all the rage. Simply put, Ajax writes code directly in the browser to enable better user interaction. The canonical example of this is Google maps (or Microsoft's Live maps, if you prefer).

For more about Ajax and Web 2.0 technologies, see The ABCs of Web 2.0.

Silverlight follows this model by allowing more expressive user interfaces in the browser. Exchanging data between the server and client using Ajax technologies (no matter which Ajax library you happen to use) allows Silverlight applications to be even more powerful. Using the rich UI model of Silverlight with the strong data transfer model of Ajax allows for incredible interactivity without forcing users to wait for page refreshes.

6. Silverlight Allows Developers and Designers to Work Together

The Web has forced development teams to think more about design and aesthetics. Responsive user experience and intuitive interfaces have become the norm instead of the exception. This happens, usually, by involving artistic and user experience skills in application development. Today, that is accomplished by employing artists to come up with the design for a website.

However, the assets that artists use and deliver are usually different from the tools that developers use. Typically, artists deliver image files (e.g., Photoshop or .jpg files) or (in advanced cases) HTML wireframes for developers to integrate into a project. No matter what technology you use, these designs must be integrated into the Web application code. As the design evolves, this integration happens over and over. Silverlight suggests a better development story. The Microsoft toolset for Silverlight is a mix of traditional development tools, like Visual Studio, and new tools that are geared for designers, called Expression Studio.

For Silverlight, the primary design tool is Expression Blend, which allows creation of XAML in a way that is comfortable and familiar to designers. Using Blend is like Adobe Illustrator or Photoshop. The big difference is that it uses the same artifacts the developers use. Blend works with the same project files, XAML and JavaScript files as does Visual Studio. When a design is created and polished, there is no integration step to use it in Silverlight. Designers can see their designs interact with the same logic that developers add as a project matures. Doing so helps designers and developers to work closely together.

7. Silverlight Deliverables Are Not Atomic

Silverlight is delivered to a Web browser in pieces. This means the code is in one or more packages (JavaScript files, assemblies, etc.), the design is delivered as one or more packages (as XAML files), and other assets are separately delivered (including images, fonts and video). First-time Silverlight developers who are familiar with Flash's single-file deliverable may consider this a detraction to the Silverlight platform.

In fact, I believe it is a benefit. The separate packages encourage the creation of dynamic server-side content much more easily than is accomplished today using Flash. It allows us to create compelling and dynamic XAML on the server and simply deliver it the way we do other markup (e.g., HTML). Silverlight has a facility for using zip files to package up multiple files that are used by the XAML code (images, videos, fonts, script files, etc.) and download them efficiently to the client, but it is not a requirement.

8. Silverlight Is New

As of this writing, Silverlight 1.0 is in a Release Candidate state and Silverlight 1.1 is in Alpha Release. This is Microsoft's first try at this sort of technology. The technology is immature compared to similar offerings by other companies, most notably Adobe's Flash and Flex products. Flash is currently at version 9.0; it has had a longer time to get ahead in both ubiquity and richness. This is not to say that Silverlight won't catch up. Microsoft has a knack for learning from others' success and failure (see Java and .NET). But it is not a certainty.

If you plan to create applications that are primarily replacements for data-driven desktop applications, you might miss the lack of basic controls and data binding in Silverlight. Silverlight is not a replacement for Windows Forms, WPF, Java Applets or Sharepoint. Simply put, Silverlight was not designed to do line of business applications in these early versions. But if you want to create rich, compelling applications with reach across platforms and operating systems, Silverlight is a good fit.

9. Silverlight XAML versus WPF XAML

It is easy to tout XAML as a great benefit because Microsoft's Windows Presentation Foundation (WPF) also uses XAML. Unfortunately, these benefits are not as compelling as it may seem, for two solid reasons: low WPF adoption and the differences between WPF XAML and Silverlight XAML.

First, anecdotal evidence indicates that WPF adoption rates are still relatively low in comparison with other client-side technologies (e.g., Visual Basic 6 and .NET's Windows Forms). So the fact that XAML has been in the wild for several years is a benefit, but it is not a big benefit in my opinion. Second, the Silverlight XAML is a simplified grammar compared to WPF XAML, so Silverlight XAML is not as powerful. This is good and bad. Silverlight XAML is very understandable, but if your developers are coming to Silverlight from WPF, it might seem incomplete.

In my opinion, the smaller grammar is actually best for Silverlight, as the runtime is small and manageable for end users. Silverlight XAML does not include anything that is not necessary for the task at hand. Certainly it would be beneficial to build more functionality into Silverlight XAML, but the current approach is to be careful about how much is added to keep the API small and light.

10. Silverlight Is a Great Way to Learn XAML

As seen in the previous section, Silverlight's XAML has a small grammar. This means it is a great way to learn how XAML works. Developers trying to learn XAML and to come up to speed on the technology will appreciate Silverlight as a way to create clear and concise code. Most developers will soon start thinking about features they would like in Silverlight. When they start looking at WPF's XAML, they will see most of those features are already there.

In contrast, developers who start with WPF and pick up Silverlight will need to give up some of the arrows in their quivers.

1 2 Page
Insider Resume Makeover: How (and When) to Break the Rules
Join the discussion
Be the first to comment on this article. Our Commenting Policies