I really do need to be more careful about what I say. But in my defense, there is no way that I could have known that an innocent little post on Silverlight would lead to accusations of bestiality.

But even without that nice little image of canine sodomy, I need to choose my words more wisely. And I get the impression from my previous post that I wasn't totally clear on my position. So I'll start by confirming that I am very excited about Silverlight. As I was with Javascript DOM manipulation, XML/XSL, XMLHTTP, and ASP.NET AJAX when each of them came out to make our lives "better". In case the tag cloud doesn't make it obvious, my interests lay in the web space. And Silverlight is almost as webby as you can get. And so, while my recent professional development has led me down some strange and wondrous paths, I will always make room in my calendar for a shiny new web technology like Silverlight.

My confusion was with the context around it. I.E. Why would you use it? (and I mean that as an honest question, not a sarcastic one). In what cases would you use Silverlight vs. a traditional web app vs. an ASP.NET AJAX one, for example. And in what cases would you combine two or three of those?

Such were the questions swirling through my head when I sat down to speak with John Bristowe, who graciously agreed to guide a friend and me through the tumult.

Side note: There is still a good sixty to seventy percent chance I would say this even if I didn't know John was going to read it but I've always appreciated his tendency to speak frankly about the technology he evangelizes, especially when talking to him directly. Not in an in-your-face, "I may work for Microsoft but I'm still a rebel" kind of way. He focuses on what it can and can't do in a very matter-of-fact way. He clearly knows his audience and their tendency to turn jaded when they detect marketing-speak so there's little sugar coating. But at the same time, he still paints things in a positive light. Anyway, that's enough Bristowe-love for now.

We discussed the many pros and cons of Silverlight of which I'll highlight only a couple here. None of the major cons struck me as being a big deal. Yes, it's early in the product's lifecycle and the tool support is still under development. But given that my favorite HTML editing tool is Notepad2, I'm okay working directly with XAML. At least I can use an XML editor if only to validate my work in some small way. In any case, I have no doubt the tool support will be there from someone when I eventually need it.

The pros were more interesting. The obvious one is the development environment. I.E. Building apps in a managed environment. This is one I kind of slammed in my last post. I shouldn't underestimate the impact of being able to write client code in C# and I welcome the opportunity but I'm also not going to shy away from a little Javascript if the situation warrants it. And for those of you who can't wait until the Silverlight 1.1 release, there are alternatives. Regardless, the fact that I can use base class libraries in a browser is a nice-to-have for me, not a make-or-break selling point. I'm just not feeling enough pain, I guess. Or rather, I'm of the opinion, "Find out what the user wants and build it. Somehow." If it involves technology that you're not familiar with or that is cumbersome, suck it up and learn. That's why you build software and users don't.

To me, the more important benefits are: the performance gains for really process-intensive client code (orders of magnitude in the hundreds!), dynamic assembly loading, and isolated storage. These seem to be more user-focused improvements over the current model. Performance gain is an obvious one but isolated storage opens up doors for customized user experiences. And dynamic loading means better perceived performance (which, as I've mentioned before, is more important than actual performance). Plus it means you can introduce more user controls in a seamless way. As my friend said afterward, it's almost as if you can extend HTML which has been notoriously resistant to extensibility for nigh on twenty years.

The fact that it integrates with my existing knowledge base (Javascript, ASP.NET AJAX) is also a big plus. It means Silverlight becomes a tool I can use when it makes sense. For example, I don't need to rewrite the entire application in Silverlight if I need some funky animation in one corner of the screen. I can drop in a control (or more likely, outsource it to a designer who knows how to make these things pretty) and carry on pretty much like I normally would. If the application calls for some fairly extensive processing and a lot of calls back and forth to the server, again, I now have another option.

Before John's initial presentation, I had a distorted view of what Silverlight would mean in my development world. Like it would revolutionize how I write my web applications. Afterward, I think I felt it was shifted back to normalcy but I felt there was something there I wasn't getting because its capabilities seemed to differ quite drastically from that distorted view. But then, we didn't really focus on the parts of Silverlight that make the marketers drool: namely, the media capabilities. The parts you will start seeing on the public websites for big corporate-type companies. My dissonance came because I think the hype applies more to these types of websites as opposed to the internal business apps I typically work with on a day-to-day basis.

I hope through all this philosophical rambling that it's clear that I did get the context I was looking for. The key to all of this, as it always is, is to remain focused on the end user. Given what I know of Silverlight's capabilities, what can I bring to the application that would make the user experience better? That was the underlying theme to the questions I had and I came away from our discussion much clearer on its place in my own personal world.

Kyle the Silverlit