I've noticed lately that a lot of people seem to have misconceived notions of what exactly Silverlight is and does. I will attempt to explain what Silverlight is and how it fits into the web spectrum in language that even your boss will understand. What I won't do is try to tell you when you should or shouldn't use Silverlight or how to build specific applications using it, those are topics for other posts.
If you have built a little prototype app in Silverlight, and certainly if you have done more than that, this post is not for you. This post is directed at those that have heard of Silverlight, think they might know what it is and would like to know if it fits their needs. It is also a good post to read to get a good general understanding of the way web development works.
IIS, Apache, etc. These are web servers. They accept the request from a client browser and return the appropriate response.
PHP, ASP.NET, PERL, JSP, Cold Fusion. These are all server technologies. They execute on the web server itself in response to requests from a client, typically a web browser. They typically output HTML.
MySQL, SQL Server. These are the databases, they also are located on a server. Typically the web server technology will have a method to connect to the database.
SOAP, WCF, REST. These are all types of web services. Typically these are created on a web server to expose data and logic to outside applications.
XML, JSON. These are data formats.
Where Silverlight Fits
As stated in the previous section, Silverlight executes in the client browser. What does this mean? It means:
- Silverlight applications need to be hosted on a web server
- Silverlight does NOT need to be hosted in IIS, any web server will do
- Silverlight does NOT need ASP.NET on the server
- Silverlight applications cannot access databases without an intermediary (like a web service)
- Silverlight applications cannot access server-side classes or variables without an intermediary (like a web service)
Silverlight also can run on any major browser (Internet Explorer, Firefox, Safari) on any major OS (XP SP2, Vista, OSX, Linux).
Programming Silverlight applications can take many forms. This is due to a number of items.
First, the plugin contains a limited version of the .NET framework. What this means is that you can write real, compiled and managed code that executes in the context of the client browser itself. What it doesn't mean is that you have access to the full framework. There are a lot of areas of the framework that are missing completely, like System.IO and others that are present but are missing features, like no ArrayList for instance. It also doesn't mean that you can build reference an already existing class library from your Silverlight application. You can still use class libraries but they must be compiled against the Silverlight version of the framework.
Silverlight also introduces what is known as the DLR, or Dynamic Language Runtime. This allows you to write code in non-traditional .NET languages such as IronPython or IronRuby.
Silverlight 2 is currently in it's second public beta and is due to be in full release this fall. It also contains a full commercial "go live" license, which means that you are permitted to use it to build real production, money-making applications with the Beta version. Silverlight 2 introduces the .NET framework to Silverlight along with the DLR and a rich control set. The majority of applications being built today are using Silverlight 2. With all of the advances in Silverlight 2 combined with the go-live license and the short timeframe until the full release, building anything in Silverlight 1 today seems wasteful to me.
Silverlight and WPF
Silverlight is a limited subset of WPF, both of which use XAML as their markup language. This allows for several things, such as the shortening of the learning curve when moving from one to the other. It also means that typically, if you develop an application using Silverlight, it can normally be ported to run as a WPF desktop application with minimal effort. Moving the other direction however, from WPF to Silverlight, can be more troublesome due to the greatly increased .NET framework and control set in WPF.
Silverlight and ASP.NET
ASP.NET and Silverlight overlap in some of their capabilities, but Silverlight is not a straight replacement for ASP.NET. Since code written for ASP.NET executes on the server it has access to the entire .NET framework, can use connection strings to access databases and can use any number of third-party or internally generated class libraries.
Even on the client, there are times when you may want to stick with ASP.NET over Silverlight. If you have parts of your application that are nothing more than data-entry forms, the standard ASP.NET controls are very well suited to that kind of work.
Silverlight and Flash
Everyone has heard talk of Silverlight being Microsoft's "Flash Killer". Personally, I do not think that is the intention or even goal of Microsoft when it comes to Silverlight. I believe that they (MS) saw a way to add more interactive capabilities to web applications in a way that is friendly to .NET programmers. I see the emerging RIA space as being plenty large enough for Flash/Flex, Silverlight and even a few others. Yes, they both do many of the same things and yes, Flash may do some of them better currently. But give Silverlight some time to mature and you will see much more feature parity between the two.
Silverlight and AJAX
Hopefully this post has helped answer some of your questions as to what Silverlight is, what it isn't and where it fits into the web space. If you have more questions or want to correct me on something I may have mistyped, please leave comments here or use the forums at http://silverlight.net.