Dev Girl's World

Silverlight Basics #1: Introduction for dummies

You have probably heard a lot about Silverlight, right? It's been a trendy buzzword recently and a technology that is cool to play with. So if you're looking for a gentle introduction to the Silverlight world, you're in the right place!

This tutorial is for you if:

• You want to learn what Silverlight is and how to start developing Silverlight applications.
• You are familiar with C#, .NET framework and Visual Studio.
• You have some idea about web application development (i.e. you are at least familiar with the basics of HTML).
• It is useful (but not required) if you know the following:
  • Flash/Java applets - because both Flash (or Java applets) and Silverlight applications are hosted by browser plugins, so there is a similar programming model,
  • WPF - because WPF and Silverlight applications have similar architecture, even though WPF is for desktop application development and Silverlight is for website development,
  • JavaScript - because in some advanced scenarios you will want your Silverlight application to interact with your HTML page.

After having read this part you will:

• know what other technologies were used before Silverlight,
• know what Silveright is and how it fits among other technologies,
• know when it is best to use Silverlight over other technologies.

If you already know all of that, you can skip this part and move on straight to the next part.. Silverlight Basics #2: The anatomy of a "Hello world" application.

So let's get started!

As you have probably already heard, Silverlight is yet another technology for creating websites. More accurately, it is a browser plugin that hosts Silverlight applications. Yet another buzzword on the list: HTML, CSS, ASP.NET, JavaScript, DOM, AJAX, ActiveX, Flash etc. And now: Silverlight. If you don't know how all these technologies work together, the next chapter is for you.

How all these web technologies work together?

Let's say you want to share with the world the list of your favorite books. The first approach would be to list the books in a text file and put it on an HTTP server, so that anybody in the world can download it and open with any text editor. Quite easy. But then you decide you want the list to look nice: have images of book covers next to the titles, colorful background and best titles to be in bold. You could use Word to achieve it but then you would limit your audience to people who have Word installed on their computers. So you decide to create a website which users can connect to and open in a browser. You learn HTML and put a nicely formatted HTML file on the server. For a maximum visual effect, including fancy borders around each element on the list, you also learn CSS and include CSS styles in your HTML document.
You receive a lot of emails with positive feedback about your new website but some users would prefer the list to be sorted by author name, and some by publication year. So you create one HTML document for each case: one file with unsorted books, one sorted by author and one sorted by year. But because you read a lot and your book list is long, users finally demand the ability to display only books that contain certain words in the title, so they can easily search for books on your list. Creating a separate file for every possible search phrase is impossible, so you decide to use a server side technology. You learn C# (or VB/PHP/Java/C/C++ etc.) and create your website in ASP.NET (or PHP/JSP/CGI etc.). No matter which technology you use, the final result is the same: you write code in your chosen language (for example C#) and this code in turn generates HTML (and optionally CSS styles as well). There is no HTML file on the server anymore, instead there's code that can generate an HTML file. The server now takes user request (i.e. sort order, searched phrase etc.), generates response on the fly (list of books) and sends it to the browser in HTML format. From the browser's perspective nothing has changed: it just receives an HTML document to display, nothing fancy here. The server takes care of the rest.
This way you can create huge, complex websites with the same functionality as desktop applications. The only difference is user interface. Desktop applications usually have intuitive and user friendly interface, including expandable menus, drag & drop, highlighting elements as you move mouse pointer over them etc. Your application doesn't have all of that and you want to make the elements on your book list expandable: the list initially contains only authors and titles but when you click a book title, it shows more details, including book cover, publisher and publication year. Of course you can send a request to the server to generate a new HTML document with detailed book information every time you click on a book title, but that wouldn't be a good user experience. You would have to wait a few seconds for the new page to download each time you click a book title. So you decide to learn yet another language, JavaScript. HTML is no longer just a static document downloaded by the browser because JavaScript modifies it on the fly. When HTML is downloaded, it is stored in browser's memory as a tree structure called DOM (Document Object Model). It contains HTML elements and CSS styles associated with them. After the website finishes loading, JavaScript takes care of the DOM structure and modifies it to reflect user interaction with the website (for example changes the font color when user clicks an element). Any change in DOM in memory is displayed by the browser on the screen. So now you write C# code that generates JavaScript, HTML and CSS, and the generated JavaScript code then modifies the generated HTML and CSS.
Quite complex, huh? But this is how most web applications look like. Such applications can be indeed hard to test and debug. HTML is more less a standard and works in a similar way in all browsers. But JavaScript adds some spice to developer's life: it varies from browser to browser and you basically end up writing separate versions of your JavaScript code for every browser you want to support. And this is not the end of the developer's nightmare! So far we have reached the state in which user clicks on an element on the page, sends a request to the server and waits for a new page with new content to be downloaded and displayed. This click-wait-display model is still far from being the experience user would have with a desktop application. The solution to this problem is AJAX, which is simply more JavaScript. Now JavaScript not only creates fancy effects on the screen but also asynchronously downloads data from the server in the background. So user doesn't have to wait for an entire new page to be downloaded anytime new data from the server needs to be retrieved. Now they can stay on the same page and continue interacting with it, and new data will be downloaded in the background and displayed when ready. This is heaven for application users - the web application finally behaves like desktop application, has intuitive interface and is easy and pleasant to use.. at the cost of developer's hell and endless sleepless nights when trying to debug their applications. If you ended up being the sleepless developer, it's time you learned Silvelight. It's not a miracle, but it can definitely solve some of your problems (and generate new ones ;).

Why Silverlight?

The previous chapter roughly describes trends in web applications in the last 10 years. There are some parts missing:

• ActiveX - At some point Microsoft came up with a technology to run executables (DLL files) in the context of the browser. The executables weren't standard Windows desktop applications but you created them in a very similar way. You embedded your application in HTML as a special ActiveX object and your application could simply render its content to the region of the browser window occupied by that object (instead of having its own separate window). ActiveX gave developers the ultimate freedom - their code could do anything, just like a desktop application, and it gave users great experience. But there were 3 main issues with this solution:
  • ActiveX only worked with Internet Explorer, other browsers couldn't execute it, not to mention other operating systems,
  • badly written ActiveX controls could crash Internet Explorer, and that wasn't a great user experience,
  • and the worst scenario: ActiveX was just executable code so it could be harmful and it often contained viruses. This made users reluctant to install new ActiveX controls.

ActiveX controls are still in use as Internet Explorer plugins or some special content on some websites (for example as sophisticated file upload mechanisms). The rule is you should only install ActiveX content you trust. Users trust Sun, Adobe or Microsoft, they probably won't include viruses in their products. But if you create your own ActiveX control and put it on your website, it's most likely nobody will want to risk and install it. So in result nobody will use your website..

• Java applets - Java applets had their five minutes of fame. They were Java binaries (CLASS files, often compressed and packed as one JAR file). Applets were hosted by a browser Java plugin. The requirement for applets to work was of course to have the JVM (Java Virtual Machine) on the computer but that was not a big deal, as Java works on many operating systems. Applets were also safe, they had very limited access to local hard drive for example, no access to system registry etc., so they couldn't execute any harmful code. The only problem was the language library. Java is a general purpose language and its standard media library only contained some simple raster drawing routines, and very poor audio and video support. Everything fancy had to be coded manually. That's why Flash took over.
• Flash - Yet another browser plugin, called FlashPlayer. It can execute Flash applications (SWF files). It won over Java applets because with Flash you can easily create animations and attractive fancy pansy vector graphics, easily embed audio and video, both in designer and with code (the language used is called ActionScript). Something Java applets didn't have.

And there comes Silverlight! It's not new anymore; it has been out there for around 2 years now. But it's the version 2.0 that gives it some real power. Here's a quick overview of how it is similar to other technologies:

• Silverlight applications are hosted by a browser plugin, just like Flash or Java applets. You have to install the plugin once, and then you can enjoy webpages with Silverlight content. Currently available for Windows and Mac, but there is an open source Linux version called Moonlight.
• Silverlight applications are simply executables (DLL files) yet they are safe. They are executed in a kind of a sandbox; they have very limited access to hard drive etc. (more less like Java applets).
• Silverlight applications are similar to WPF applications: with XAML, similar architecture, layout, template and styling system, very similar class library etc. Silverlight is more limited though, for example it doesn't have 3D graphics support yet (it is planned for Silverlight 3.0).
• Silverlight has a rich media library making it easy to develop rich applications with fancy vector graphics, animations, audio and video - more less like Flash.
• A big advantage over Flash: one language, one environment, one set of development tools. Flash objects have their own separate world, with separate language. Silverlight uses .NET, so if you know C# for example, you know how to write Silverlight code. Plus you use the same tools to develop server side (ASP.NET) and client side code (Silverlight) - you simply use Visual Studio 2008 SP1 for all of that. With all the advanced debugging features and so on.
• And one of the flag features of Silverlight: separation of code and design. You design your application's looks in XAML and this is something a designer can do in Expression Blend. Then you code the logic in Visual Studio, and this is job for a developer.

Now that you know what Silverlight is, you may be wondering why people invented so many technologies over years to make a browser act as an application host, instead of just writing desktop applications. Yes, desktop applications are easier to develop. But imagine you have to install a separate application for every of the 20 websites you visited today, and another 30 yesterday.. Now you understand why there is Flash and Silverlight, right? Cause you just install the plugin once, and then enjoy rich web content. Plus there is still some portability across browsers/operating systems - not 100% because some plugins are not accessible for some browsers/OS, and JavaScript works differently across browsers but still it's better than developing a separate version of your application for every OS version, as it is the case with desktop applications. And we should mention security: web applications run by plugins are usually harmless, but desktop applications can contain a wide range of harmful software. So you usually don't run desktop applications you don't trust or don't know where they come from.

Once again, a quick reminder:
Server side technologies (executed on the server): ASP, ASP.NET, PHP, CGI, JSP.
Client side technologies (executed in the browser): JavaScript, ActiveX, Flash, Java applet, Silverlight.

Summary

You should now understand how websites evolved over years from simple static documents to rich applications similar to desktop applications, and how it made development complex. You should also know what is an advantage of using Flash or Silverlight for such rich web applications over just HTML and JavaScript.

Now it's time to move on to the next step.. Silverlight Basics #2: The anatomy of a "Hello world" application.