By now you’ve probably heard that we’ve shipped Silverlight 2.0. Many folks love it, some folks don’t care.

Though I avoided spend much time at all with Silverlight 1.0 and resisted 2.0 until it neared commercial quality delivery, my personal interest is just gaining momentum. So now that Silverlight 2.0 is an officially released product I thought I’d share some thoughts.

When it comes to software development, I tend to be PRAGMATIC above all else. I’m not one of those guys (and we have them here at Microsoft, even on my own team) who emerge themselves in the latest technology for little more reason then that fact that it’s the “new thing”.

Don’t get me wrong, we NEED those guys. They will flush out the problems and shape the technology that the rest of us will be using in 5 years; it’s just not where I choose to spend my limited time.

My preference is to focus on the technology that can have meaningful impact on the next 6 fiscal quarters at the customers that I work with and to help Microsoft Developer Product feature teams understand what customers need and want relative to what he have already delivered.

So, Silverlight 1.0 was of only passing interest to me. Silverlight 1.0 has a GREAT media story but it didn’t fire me up.

Silverlight 2.0 (and what’s coming in 3 and beyond) has my attention.

The most common questions I get about Silverlight are in the “Flash Killer” category.

Why would I switch, and isn’t this just Microsoft wanting to take some of Adobe’s market.

Sure, Silverlight, in some regards is vying for adoption in what might previously been Adobe Flash land. Just as Flex and Air are competing for the more conventional developer audience that has been largely a Microsoft customer base. 

The things that Flash and Silverlight both do well are of little interest to me either. Flash has a nearly ubiquitous adoption. If simply streaming standard web video or adding <object> based user interface glitz to my application were my goal, I might never dive deep into Silverlight.

But, my pragmatic nature forces me to additional considerations.

If you’ve ever heard me give a conference keynote you are likely to have heard me quote Albert Einstein who said, among many other brilliant things, “The SIGNIFICANT problems of today cannot be solved with the KINDS of thinking that created those problems in the first place.” 

This is the facet of new technology that excites me the most; the ability to examine problems both new and old, and think about solutions that were not possible with the technology available to us even a year or two ago.

Enter Silverlight 2.0. Below I’ll highlight some of my favorite attributes of Silverlight 2.0 and mention why I think they change things.

1.) CLR based runtime.

The browser embedded runtime will change what we can build in our browser based applications. Now, it’s not the first time we, as an industry, have tried this browser extension thing. ActiveX failed because it lacked a mature security model. Java Applets failed for a variety of smaller reasons. Different browser hosted JVMs yielded vary different renderings, while there were security flaws the restrictive sandbox prevented the use of client side resources, they were hard to write, internet connections at the time were too slow, and Sun was far more interested in the server side story for Java.

All the above issues aren’t here to inhibit Silverlight 2.0 Application deployment.

The Silverlight 2.0 runtime is tiny and the applications are even tinier, but the performance of code execution is FAST. This download and execution performance opens up new doors for us to implement complex client side logic, including rich business implementation running right there in our browser hosted application. What’s more, writing these applications will be easier due to the rich .NET Framework subset that is implemented with Silverlight 2.0.

What’s more, if you ware already a .NET developer, your learning curve is minimized because Silverlight Development is .NET Development. If you are building WPF applications, you’ll add Silverlight to your toolbox and feel like you never left home.

2.) First class language support.

JavaScript, EcmaScript, ActionScript, whatever your particular flavor, they’re all pretty much the same coding experience. It’s not that you can’t do meaningful work in JavaScript; there is a ton of great stuff out there in JavaScript and ActionScript. Though much of that code is clever, it’s “behavioral”. Its script code whose primary purpose is to manipulate the UI and ship the needed data back to the server for the real work or to take the product of the server’s processing and present it to the user sitting in front of the browser.

This model does nothing to distribute processing between the client and the server and, from a user experience perspective, we are restrained by the semantic requirements of the traditional Web based Client / Server implementation scenario.

The fact that we can write in JavaScript does mean we should. I wrote a lot of Assembler and COBOL code back in the day and I’ll be happy if I never return to those syntax flavors.

I rather like JavaScript for its intended purpose. It has a quick and dirty feel to it and lets you run loose and wild. This is great for wiring stuff up, but not such a good thing for implementing real application logic. The feel of JavaScript that I like for manipulating the DOM, etc. becomes a sort of “inelegance “ when needing to get down to real logic implementation and the long term impacts of JavaScript’s casual nature causes me great concern because business logic, even when functionally perfect, will absolutely need to be revisited from time to time and the business needs or culture change.

With Silverlight 2.0 we can implement our logic in C# or VB.NET if we choose to leverage full OO constructs, strong typing, and the like.

If you lean to the Dynamic Languages view of the world you can choose Python, Ruby, PHP (Phalanger) and whatever languages might be implemented.

3.) XAML

First, please understand (and embrace) the fact that XAML is NOT just a presentation syntax. XAML is an Extensible Application Markup Language. This means that is can be used to define any type of .NET object, behaviors and associations.

The use of XAML for Presentation definition in WPF and Silverlight is only one possible use and a broader use of XAML will create very interesting scenarios.

XAML is interesting to me for many reasons, but let me be say up front, I hope to never write a single line of XAML code “by hand”. That fact that you COULD write XAML by hand is not where the power is. In fact, if you had to write XAML by hand, it would never happen. (Just like SOAP, and many other useful XML dialects.)

First, XAML is important because it is a verifiable XML syntax which means tools (like designers and IDEs) can reliably read it and interpret it in identical ways. This is very important because it means that we may, after many attempts in the industry, actually have a development process where developers and designers can truly work on the same project with their respective tools of choice in a very seamless way (read NO technology conversions / translations ever time the work product passes across the designer / developer boundary.)

Next, XAML is XML. Lest we forget the “X” means EXTENSABLE. This means that the base syntax for XAML can (and will) be extended by developers and vendors for specific purposes and this can be done without breaking the base implementation.

Also, XAML enables Vector based rendering. Bitmaps are fine for photos, but as the variety of display devices continues to increase with a huge disparity in screen size and resolution, bitmap driven user interfaces are sure to vanish.

4.) Timeline based behaviors.

My video and animation contacts tell me that Timeline based design experience is a huge thing.

From a personal experience, as an artistically challenged geek, the Timeline based design process is simple enough that even I can do some reasonably good work in the tools. (It’s just like editing a video.)

5.) Isolated User Storage.

Remember the Einstein quote above? If you ask me, user configurable client storage is pure genius. Think about the things you can do with it. Need REALLY rich view state? Put it in client storage and drastically reduce your state driven HTTP traffic. For that matter, do it with ALL our state data. Client profile, etc.? Not only can you save all that traffic and server resource consumption, but you can still keep the master copy on the server so that you can reconstitute it on the client when a user connects from a new machine. How about client side object persistence? (Even for objects that get manipulated on the server.)

And think even beyond those possibilities. How might we use client side storage to enable “not-always- connected” application scenarios?

And how about integrating client side storage with Microsoft Live Mesh services or the Cloud Computing technologies that you will start hearting about at PDC J ? The possibilities are only restricted by our own creating abilities.

6.) Sockets Support.

Sometimes you need RAW SPEED. Silverlight 2.0 provides a well factored class collection to implement client side Sockets conversations in your applications. This means you can “speak sockets” which are supported on about every server platform since the birth of the World Wide Web, and bypass the overhead of HTTP if you need the extra performance. This way, if you need to build a chatty application you won’t have to worry about the platform painting you into a performance box that would require a massive rewrite.

7.) Enhanced Media Experience.

I mentioned earlier that the idea of streaming “standard” video wasn’t so interesting to me since there is a bunch of technology out there that already does a pretty good job of this.

Note the emphasis on “standards”. In the long term, Silverlight hold some very interesting promise for steaming media. Apart from the great Codec and High-Def work the Silverlight Team is doing, the “built in” performance throttling in Silverlight is bloody brilliant. In layman’s terms, the Silverlight infrastructure will dynamically adjust the stream based on network conditions (like latency and available bandwidth) in order to deliver optimum viewing quality with as little of the “pause and stutter” that we often experience in our Flash or Real based streaming video experiences.

And don’t forget to think about the business logic that we can add with our Client Side C# or VB.NET code. By combining metadata in the video stream and interpreting users behavior while viewing the videos, we open up LOTS of new and exciting opportunities. I’m playing with a “Smart” Video Player for all the technical How-Do-I videos that we publish on www.asp.net

8.) Expression.

Last, but not least, the Expression tools that support Silverlight (and WPF) are slick. Already in version 2, they are enjoying great popularity and rapid adoption from both new users as well as the traditional “design” community. Sure, there are folks that would like Adobe to add XAML support to Illustrator, etc., but at least there are very good, and complementary tools for folks doing Silverlight 2.0 development

So that’s a look at what I think is important and exciting about Silverlight 2.0 and it’s release this week.

I hope you’ll share your thoughts on the subject with me.

Article Global Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon Eli Pets