I previously blogged about why I stopped coding in Silverlight 1.1. I want to make it clear that that is in no way an indictment of that technology. It's just that I've learned from it what I wanted to and have moved on.

While I find 1.0 great for web gadgets and media, and found 1.1 very interesting to learn from, Silverlight 2.0, is what really excites me. It does for several reasons, some of which may not be immediately obvious when you look at the technology.

Silverlight 2.0 is Powerful

The more I play with Silverlight, the more I am amazed at just how much you can really do in it. 1.0 was about media and graphics. 2.0 is about RIA. 2.0 is also about Cross-Platform Line of Business applications which I'll be talking about that in my webcast in March.

Don't make the mistake of tossing Silverlight in the same bucket as Flash. While they definitely compete in some significant areas, and both have real strengths in different areas, Silverlight 2.0 was created from the ground-up to be an application development platform equally friendly to designers and developers. If you're a .NET developer (or want to be), you'll find the .NET framework included with Silverlight to be extremely capable and powerful.

Silverlight 2.0 Leverages your .NET Skillset

Using .NET for server-side applications or for other desktop applications? Maybe you're writing .NET code for SharePoint, or BizTalk, or Office, or any number of other platforms that support .NET. You can now add another supported platform: the browser client. From a developer perspective, this helps minimize the number of different syntaxes you need to keep in your head. From a management perspective, it means you will be more free to move people between tiers or between projects, without retraining them. In both cases, you can make the most of what you've got.

Silverlight 2.0 is Cross-Platform and Cross-Browser 

You have all the power of a trim .NET 3.5 framework running in a browser, cross-platform. You can build rich internet applications that don't care which browser they sit in, as long as there is a Silverlight plugin for it. You don't have to worry about minute rendering differences between the different browsers, or how one line of code will work on one vs. the other. Nope. You have C# (or VB, or DLR) and you have your standard rendering surface.

Most web applications that attempt to be cross-browser in any real way are full of code that detects differences in different browsers or, at the least, they choose to go with the least common denominator across them and implement a sub-par experience. That goes away, and IMHO, qualifies as a BFD.

Mobile and Devices

Not much gas been annouced on this yet, but we've all seen the MLB demo that was done at MIX. Silverlight will be on mobile devices at some point - yet another place where you will be able to leverage the same skillset and knowledge.

One other big thing that is exciting about Silverlight is not really something in Silverlight; it is a side-effect it will have on WPF.

Increased WPF Adoption

In a nutshell, Silverlight is a cross-platform version of WPF, optimized for the browser. While Silverlight brings a lot to the table in a browser-based cross-platform application scenario, it is not necessarily the right choice for all your applications. There are lots of places where web applications are still the norm, but shouldn't be. I've had clients ask me for "a web app that..." and then go forward to list a bunch of things that would be difficult to do in a web app, and which must run in their Windows-only, IE-only intranet. For those people, I used to do my best to get them to adopt Windows Forms, as the development time is quicker, and the resulting user experience (performance and features) almost always better than a similar web application.

Unfortunately, many folks still insisted on web applications to the detriment of the user experience and the project budget. Sometimes there are legitimate reasons (like if the app is actually on the internet available to the public). More often than not, though, it was because one of these reasons:

1. Web applications are easier to deploy 
2. AJAX applications are as good as desktop applications
3. Web applications look more modern

#1 is based on problems folks have had deploying applications in the past. I won't go into detail here, but there are many many ways to get applications deployed to desktops without running into issues or running floppies around to each machine. I can't blame them for the perception, though, as we've all been burned by deployment problems in the past. It's time to move forward, though.

#2 is an unfortunate result of the great job the various AJAX library vendors have done. AJAX isn't about replacing desktop applications, it's about building better web applications. Despite the power and flexibility of the various AJAX libraries, you still have to deal with a lot of web application baggage, and are still constrained by what you can do on the client. As an aside, calling many AJAX applications "thin clients" is a misnomer, IMHO. Once you look at how much javascript gets downloaded to the client, and then how much is in the page, "thin client" really becomes marketecture. Again, there are definitely scenarios where AJAX fits, but it needs to be evaluated against the requirements project-by-project, not mandated.

#3 is something that WPF directly addresses. It's true that battleship gray applications look really dated. It's also true that trying to make a Windows Forms application look like a web application is a pretty time-consuming process, especially if you are limited in what third-party controls you can get. I've done it, and the result was decent, but not perfect. The effect that had on the users though, was amazing. The application felt fresh and modern like a web app, but performed the way they expected it to - like a Windows app.

WPF now brings a much easier model for creating a compelling UI to the ease of development of a desktop application. When you add in some of the cool binding and other features of WPF, it really makes for a very productive development platform and a very rich user interface. Adding in the 3d support just makes it all the more useful, although the use of that in business applications is still being felt out by many.

Unfortunately, WPF hasn't taken off like I'd like it to. I think Silverlight is going to help change that.

What Higher Silverlight Adoption Means for WPF

Silverlight hits a sweet spot in that you have desktop-like functionality and the "web application/cross platform" check-off. (Don't get me wrong, in many cases "web application" is more than just a check-off - it's a real requirement, but that's not the target I'm addressing here at the moment.) For those reasons, I expect Silverlight to have a much higher rate of adoption than WPF did.

Once developers become familiar with Silverlight 2.0, they'll inevitably want more features and power. They, and astute management, will realize that if they code some applications in WPF, they can use the same skillset (much of the same code and xaml in some cases) and take advantage of the additional features WPF provides, including full access to the entire .NET framework and W*F. It's not the massive rewrite and skills wipe you'd expect when moving between technologies.

Silverlight Will Change How We Build Applications

Developers will be able to choose between writing powerful and rich desktop applications or powerful and rich browser applications, and won't have the massive skillset difference between the two that exists today. This is what the .NET framework was promised to be all about. This will change the way we write applications in the coming years.

Now that's exciting.