Introducing Silverlight 2
- Where Does Silverlight Come From?
- Using Third-Party Plug-Ins
- Running on Multiple Platforms
- Making the Web Application Secure
- Introducing Silverlight.net
- What Do You Need to Run Silverlight?
- Updating Your Runtime-Automatically
- Trying Silverlight Demos
- What Do You Need to Develop Silverlight?
- Reading the Documentation
- Looking into Silverlight's Future
- Summary
IN THIS CHAPTER
- Where Does Silverlight Come From?
- Using Third-Party Plug-Ins
- Running on Multiple Platforms
- Making the Web Application Secure
- Introducing Silverlight.net
- What Do You Need to Run Silverlight?
- Updating Your Runtime—Automatically
- Trying Silverlight Demos
- What Do You Need to Develop Silverlight?
- Reading the Documentation
- Looking into Silverlight’s Future
It all started when Microsoft presented its revolutionary user interface (UI) framework, Windows Presentation Foundation, to an enthusiastic crowd of graphics designers, software developers, and businessmen in March 2006 at the new MIX conference in Las Vegas. Microsoft also added one session about a lesser-known technology with the rather barbarian name Windows Presentation Foundation Everywhere, or WPF/E. There was nothing much to see yet, but the abstract was enticing: “With WPF/E you’ll be able to build rich, interactive experiences that run in major Web browsers on major platforms as well as on mobile devices.”
A little more than a year later, at the second edition of the same MIX conference, Scott Guthrie (general manager at Microsoft, responsible for most of the .NET teams) climbed on stage and gave the crowd an amazing software demonstration. The barbarian WPF/E was gone; in its place was Silverlight (see Figure 1.1).
Figure 1.1 Microsoft Silverlight logo
A bright new logo revolved on the screens. Gradients and animations were all over the place. Planes flew over the web browser’s window, connecting US cities while Scott was planning his next trips; a chess application let the browser’s JavaScript engine play against .NET, demonstrating without any doubt the superior power of the compiled .NET application over JavaScript’s interpreted code. Yes, the browser was running .NET!—not only in Internet Explorer but also on Firefox! And yes, even on a Macintosh computer.
It was an intense hour! Later that day, more demos of the new Expression Encoder were presented, which allows users to produce movies and run them in the web browser, after having copied them to a streaming (or to a nonstreaming) web server. Even better, with the Expression Encoder you can now change the look and feel of the video player completely, basing your work on predefined templates, but also changing everything from colors to shapes in Expression Blend.
These first demos were only the start of an amazing three days packed with Silverlight content. In a little less than a year, Silverlight had made it from little-known side attraction to major technology with a huge potential.
Where Does Silverlight Come From?
A little history can be interesting to understand where Silverlight came from, and how it is positioned among the many UI technologies available today. Depending on your past experience, you may be well aware of the facts presented in the next sections. In that case, feel free to skip ahead (the next interesting section for you will probably be “Running on Multiple Platforms”). If you don’t want to skip ahead, or if you feel like refreshing your memory, keep reading as this section and the next few sections fast forward from the antiquity of the World Wide Web to the magic of today.
Web pages have been around for a long time. In fact, HTML was presented to the world as early as 1992. (You know the old line about dog years being equal to seven human years? Well, 1992 in computer years is, like, Middle Age for humans!) Of course, HTML was limited in the beginning. Web pages were simple, composed mostly of text and hypertext (the most revolutionary idea of HTML, and the origin of the name Hypertext Markup Language).
Very quickly, however, the inventors of HTML saw the need for richer content to be made available in web pages. The first step in that direction was the invention of the IMG tag, allowing images to be placed inline. The basis for richer content was there, and the first popular web browser, Mosaic, displayed these pages.
Automating Web Pages with JavaScript
The next big step forward in the quest for rich content was the addition of a JavaScript engine running in the web browser.
This programming language (added in 1995 to the Netscape web browser, and then in 1996 in Microsoft Internet Explorer) enabled a much richer interaction with the user. Earlier, the only possible user action was through a postback to the web server, meaning that any data entered by the user had to be sent back to the server for handling, and the result was returned as a response. Obviously, this model was slow, especially at the time of dial-up connections.
With JavaScript, it was possible to provide a basic treatment of data on the client directly, without postback. A first obvious use for this client-side technology was a prevalidation of data, making sure that the user was not sending useless information to the server, wasting bandwidth and valuable server time. With JavaScript enabled, errors could be caught early, and faulty data would never leave the client. Of course, as soon as a web server interaction was needed, for example, to retrieve data, for complex calculations, to authenticate users, and so on, a postback was needed. This model still prevails in many websites even today.
Cascading Style Sheets
Another big step forward in the creation of rich web content has been the creation of Cascading Style Sheets (CSS). Finally a separation of content and layout was made possible. The look and feel of a web page could be extracted from the page itself and governed by the use of rules placed in external files. This model has many advantages:
- The responsibilities can easily be shared by various teams, depending on their skills. Graphics designers can be in charge of the look, developers of the functionality, while marketing is in charge of the content.
- In smaller projects, the developer can concentrate on the page’s structure and functionality first, and create the look later, after the content is fully known. This way of working is much more efficient than doing everything at the same time.
- The page’s look can be changed easily without touching the page itself.
- Same styles can be reused over and over again without having to rewrite the code. Classes can be located in a central location and referenced anywhere. In fact, it’s even possible to have styles on a central server and be used on other web servers, related or not.
As CSS became more and more sophisticated, the pages became more and more beautiful, to a point where the aspect of the pages, in some cases, becomes as important as the content itself. One can argue endlessly whether that’s a good thing (after all, content is what users are really looking for, isn’t it?), but if you can choose between boring content and beautiful content, surely the beauty will make the experience more pleasurable.
Progressing to DHTML
As the JavaScript and CSS engines became more advanced, some interaction was made possible between them. DHTML (Dynamic HTML) was born. Actually, DHTML is not a technology; it’s a combination of JavaScript and CSS used in the context of HTML.
Using JavaScript as a programming language, it is possible to access elements of the page itself (content and style), and to modify them. Since this is client-side technology, no interaction with the server is required for this kind of effect.
Because CSS allows the setting of an element’s opacity, it is possible to create fade-in/fade-out effects. With the possibility to set an element’s position in an absolute manner, JavaScript allows you to move an element across the screen. In addition to “just” adding some kind of intelligence and good looks to the web pages, the interaction between CSS and JavaScript enabled the creation of richer, smoother web pages.
Although this all sounds nice, DHTML is rather limited:
- Opacity is not supported in all browsers, and the ones that support it don’t use a standard syntax, making it kind of a maintenance nightmare.
- Moving elements across the screen can only be done at limited speed and is not as smooth as you would want.
- It is impossible to rotate elements. If you want to show a rotated button, you need to simulate this using multiple images, and the effect will not be smooth.
- Text (such as a title, in a logo, etc...) can only be rotated by using images. In that case, the localization becomes a nightmare, because you need to translate each image in each language you want to support.
- The “hit test area” for any element is always square. In other words, even if you have an image of a round button with a transparent background, you may activate the action even if you click outside the round area. The mouse cursor will turn to a hand even though the mouse is still on the transparent area.
Thankfully, Silverlight corrects all these shortcomings, and since it can be “blended” among HTML elements, it offers a real possibility to graphically enrich a web page.
Communicating in a Richer Way with AJAX
In addition to enabling DHTML, JavaScript brought a huge improvement to client-server communication, and to creating a smoother user experience: Asynchronous JavaScript And XML (AJAX), a cumbersome name for a great technology. In short, AJAX allows JavaScript to send a request to the web server, and to get the response without the web page being refreshed. Instead of using the normal postback mechanism, the whole communication occurs in the background, and the user doesn’t notice it.
With this technology, the user can get additional information from the server without losing the context he is working in. The user experience is also much smoother, because new information gets loaded without the “traumatic” reloading of the page and the temporary white screen caused by it.