Despite all the wonderful things you can say about HTML, CSS, and JavaScript, I think most people doing a lot of web-based development would agree that they form a pretty poor environment for developing modern sites and applications. If you care about your content working on most web browsers (or even just Internet Explorer and Firefox), accommodating their differences can be maddening. Many techniques and JavaScript libraries have been developed and shared over the years that can reduce this frustration, but none of them are silver bullets.
In addition to browser differences, the graphical capabilities of HTML are too limiting for many user experiences that people want to create. Drawing a simple line, incorporating video, and a number of other things are extremely difficult or impossible with HTML alone. It’s not that these technologies were poorly designed, but simply that they were designed for hyperlinked documents rather than the extremely rich presentations that most people want to create on the Web these days.
Considering these issues, it’s no wonder that Adobe Flash has been so successful. Whether someone wants to create a professionally designed website, an online game (or any number of other applications), or even a simple advertisement, Flash has been a natural choice for escaping the limitations of HTML. If you doubt the pervasiveness of Flash, try this experiment: Think of a brand of food you eat, and then navigate to the brand’s website. Chances are you’ll find Flash content at your destination. (I just tried pepsi.com, doritos.com, and oscarmayer.com, and all three are using Flash at the time of writing.) The Flash development experience leaves much to be desired, however. Flash (the runtime environment, as well as the tool) suffers from the same basic problem as HTML: Many people are trying to use it for creating rich applications, but it was originally designed for something else (in this case, simple animations).
This is why the introduction of Silverlight is so exciting. A promising alternative to Flash, Silverlight enables the creation of rich web content and applications using a lightweight add-on that is friendly to both designers and developers. Yes, the first version of Silverlight is primitive in areas, but it’s a true development platform based on concepts and APIs introduced with Windows Presentation Foundation (WPF) in 2006 and in development for many years prior. And, unlike just about any software that has come out of Microsoft, Silverlight is a small download! Version 1.0 is less than 1.5MB, so users who don’t have it can get it pretty quickly when browsing to Silverlight content. (By default, Silverlight also automatically updates to later versions when they are available.) Silverlight might just be the silver bullet many designers and developers have been waiting for.
Silverlight 1.0 applications are created with a mixture of XAML (Extensible Application Markup Language), HTML, and JavaScript, so they are easy to integrate into existing web content and compatible with popular Asynchronous JavaScript and XML (AJAX) libraries and techniques. XAML is an XML-based declarative language described in depth in the next chapter. In typical Silverlight applications, a XAML file contains a hierarchy of visual elements that must be rendered on the screen. Silverlight parses the XAML content on initialization, and then renders the content as appropriate.
Digging Deeper
A Note for Those Afraid of JavaScript
A few readers might be excited at the idea of using JavaScript to create Silverlight content or applications. If you’re like most developers I know, however, you’re disappointed to be “forced” to use it in version 1.0. However, programming in JavaScript isn’t the worst thing in the world. JavaScript is a very powerful dynamic language, and you can even use it in an object-oriented way if you follow clever patterns that people have devised over the years. (Note that JavaScript really has nothing to do with Java.)
In addition, now that Asynchronous JavaScript and XML (AJAX) is all the rage, there are a number of useful tools and libraries to help you be productive with JavaScript, and they keep getting better. Visual Studio 2008 boasts a number of improvements for JavaScript develop-ment, especially related to debugging and IntelliSense.
The pain of programming in JavaScript (when used as part of a website) is often not because of the language itself but rather differences in the HTML Document Object Model (DOM) provided by various web browsers. Fortunately, writing JavaScript that interacts solely with Silverlight objects doesn’t have this issue because the Silverlight object model remains the same regardless of the host browser. Most Silverlight applications still require JavaScript that interacts with the HTML DOM, but your exposure to the DOM can be much more limited. And for those cases, ASP. NET AJAX (or other popular AJAX libraries) is a good fit for hiding browser differences.
If you’re still not convinced, rest assured that the next version of Silverlight (already available in prerelease form) supports procedural code written in C#, Visual Basic, IronRuby, IronPython, and other .NET languages. And for those who love JavaScript, the next version of Silverlight should support compiled (.NET-based) JavaScript, giving performance that is orders of magnitude faster than the interpreted JavaScript running in browsers today. Some of these languages will be part of the core Silverlight download, whereas other languages might require additional on-demand downloads.
FAQ: What are the differences between Silverlight and Adobe Flash?
“Flash” is the name for both a runtime component and a design tool. “Silverlight” refers to a runtime component only, but there are both design tools (such as Expression Blend) and development tools (such as Visual Studio) for Silverlight. For years, Flash has been the only viable option for rich web-based content, and now Silverlight is positioned to fill the same need. The two technologies have similar features, but there are naturally pros and cons to each.
The biggest thing Flash (the runtime component) has going for it is ubiquity. A website can use Flash with confidence that the vast majority of viewers already have the necessary player installed. Silverlight, on the other hand, is brand new and will take some time to spread— dependent on the amount of compelling Silverlight content out in the wild. Of course, both Flash and Silverlight are designed to have a quick and painless installation, so sites don’t have to inconvenience users too much if they don’t have the necessary software. But even if Silverlight spreads like wildfire during the first few months, the Flash runtime component can still reach places that Silverlight can’t (yet), such as mobile devices.
Flash has a variety of visual features that Silverlight lacks, such as bitmap effects (blurring and glowing) and shape tweening (morphing the shape of an object in an animation). Notable features of Silverlight that Flash lacks are higher quality video (even HD 720p full-screen with reasonable hardware) with VC-1 codecs included, seamless interaction with HTML, support for high-resolution and pressure-sensitive input data from a stylus or touch device, and content that’s more discoverable to search engines by default thanks to the use of XML rather than compiled script.
The biggest advantage of Silverlight over Flash is in the design of the platform and its associ-ated tools. This advantage becomes especially apparent if you’re building an interactive appli-cation rather than a simple piece of content. Flash (the design tool) has a huge learning curve for creating an application with even a small amount of logic, and the resulting code is often quite unnatural (and hard to debug). But most software developers, or even people who dabble with HTML and a little bit of programming, should find the learning curve for Silverlight to be pretty small. And if you happen to already be familiar with WPF, learning Silverlight is a breeze.
FAQ: What are the differences between Silverlight and WPF?
Whereas Silverlight is designed for creating rich web content or applications that can be viewed in multiple browsers and multiple operating systems, WPF is designed for creating rich Windows applications. WPF applications require the .NET Framework 3.0 or later, which is a much larger download than Silverlight, although Windows Vista and later operating systems already have it installed by default.
Silverlight 1.0 is essentially a subset of WPF, although Silverlight also has a few unique pieces related to video, on-demand downloading of any content, and the control that hosts the content inside a web page. Some WPF features missing from Silverlight 1.0 are common user interface controls (such as buttons and scrollbars), layout panels, 3D graphics, data binding, rich document support, performance optimizations from hardware accelerated graph-ics, and more. In addition, Silverlight 1.0 applications don’t have the benefit of the depth and breadth of the .NET Framework APIs, unless you use them from server-side ASP.NET code. The next version of Silverlight will close some of the gap between Silverlight and WPF, but it will undoubtedly always remain a subset of what WPF and the full .NET Framework provide.
Although Silverlight 1.0 coding is done in JavaScript, which is a big departure from the .NET languages used with WPF (and future versions of Silverlight), the two technologies are highly compatible. In some cases, Silverlight code related to user interface—especially XAML content—can be reused in WPF applications with little work, and vice versa. The key to choosing between Silverlight and WPF is whether you want to optimize for reach or for rich functionality. This is really no different than the classic choice of going with a web application or a Windows (or other OS) application. Besides aforementioned features such as 3D graph-ics, WPF applications are a natural choice if you require offline support or extensive local storage.
WPF doesn’t only support Windows applications, but also applications that run inside the browser called XAML Browser Applications (XBAPs). XBAPs can arguably be considered web applications because their content renders seamlessly inside the browser similar to Silverlight content. However, XBAPs require the .NET Framework 3.0 or later, so they only run on Windows (and only then if the .NET Framework is installed) and only work inside Internet Explorer and Firefox. (Furthermore, Firefox support requires the .NET Framework 3.5 or later.) XBAPs support a much larger subset of WPF functionality than Silverlight 1.0, so they can be an appropriate choice for creating very rich applications that are web-like in their deployment.
For example, the British Library has an application called “Turning the Pages” that takes advantage of WPF 3D graphics inside the browser.
FAQ: What is the relationship between Silverlight 1.0 and the prerelease version of Silverlight?
It’s a bit unusual that the next version of Silverlight (currently labeled 1.1) has been available in a prerelease form before Silverlight 1.0 was even finished, but as the version number suggests, it simply is the next version of Silverlight. This next version is a superset of Silverlight 1.0 and is still a subset of WPF and the .NET Framework (but with some unique features of its own). The most notable additions planned for the next version of Silverlight are
|
Despite all this, everything you learn about Silverlight 1.0 is directly applicable to future versions of Silverlight.
FAQ: What web server is required for serving Silverlight content?
Any web server will do, although be sure to set up the MIME type for .xaml files. Using Windows Server can give additional benefits when it comes to streaming media, such as the Faststream technology in Windows Media Services. Silverlight Streaming by Windows Live can also be an attractive option for hosting Silverlight content on someone else’s web server. It supports scalable streaming free (if you don’t mind advertise-ments being served with your content) or for a small fee.
FAQ: What are the differences between Silverlight for Windows, Silverlight for Mac OS X, and Silverlight for Linux?
Silverlight supports the same feature set, because it is designed to be completely compatible between all the operating systems and browsers it supports. One advantage Silverlight has on Windows is the ability to get high-resolution and pressure-sensitive input data from a stylus or touch device, although this extra information is given in a way that avoids the need to write Windows-specific code. (See Chapter 7, “Responding to Input Events,” for more details.) Silverlight also has different performance characteristics on different browsers and operating systems. For example, windowless controls (described later in the chapter) and elements with transparency are especially slow in Safari on Mac OS X. And of course, Silverlight has bugs that only apply to a specific browser or operating system. Some of these are pointed out in this book.
