I was going to argue against Silverlight being the future, but yesterday my reserved copy of “Beginning Silverlight 2:” came in at the library and my copy of “Silverlight 2 in Action” arrived in the mail. So maybe the Colossal Cosmic Anvil of Fate is dropping on my head and telling me something.

I don’t think that in 5 years, every web developer will be programming in Silverlight or Flash. What I think is going to happen is that the web browsers are going to evolve and include more Silverlight/Flash like features. We already see that happening with isolated storage in FireFox and IE8. FireFox already has a rich network of extensions that allow developers to enhance services in many different ways, Google Chrome has released their draft extension specifications. IE8 and Safari still have a way to go, writing extensions for either is a non-trivial exercise.

There’s a reason that developers haven’t written these types of RIA’s using Flash for the past 10 years even though it has been possible. It’s not the lack of tooling, it’s the plugin. Even though the Flash plugin is a small enough download and easy to install, in my experience developers have been hesitant to build an application that is dependent upon a plugin. I don’t think that will change with Silverlight, even if Microsoft ships it in Windows out of the box or includes it as a mandatory update in Windows Update, there will be IT departments that either will disable it or won’t keep it up to date.

What do you think will happen?

(I’m sure some British Linux fans are getting a chuckle at that one. Or maybe their caught in the Giggle loop?)

Why write code that I can’t run?

I’ve got a pretty good handle on the object model, enough that I think I may take it back up when I get an Intel based Apple computer.

I'm not a big fan of the declarative UI movement. (XUL, Apollo, XAML, and now JavaFX). The reasons given for declarative programming usually center around making the UI code human readable making a cleaner break between the UI(view) and the controller(code driving the view). But UI's are complicated things, the code or markup used is complicated also. So what's the first thing most developers do? They go find a tool that makes sure they never, ever have to deal with the complicated markup and code. So if you're never going to read the UI code, why bother making it human readable? Apples Interface Builder has known this secret for years.

Interface Builder stores user interface resources in "nib" files. Nib files are a statically stored representation of the set of interface objects used by the application and their relationships which can be efficiently brought into memory when needed, reducing development time and making it easier to localize an application for different markets.

You could make an argument that Nib = binary XAML. The UI is "freeze dried" at design time and then reconstituted and instantiated at run time.

If you search for "Why use XAML", the pages of results never tell you what the advantage of using XAML over imperative code is. The results just say, "WPF uses it. That's why you have to use XAML".

That isn't to say there aren't some benefits to working with XAML. I love the fact that I can dump ALL my markup and UI code in one file, and concentrate on manipulating the UI in another. You could do that during standard Winforms development, but it wasn't as easy. I'm all about easy. The ability to define timelines and animations within XAML put it above the Nib format.

What benefits do you see in using XAML?

"Silverlight V1.1 will only target Intel Mac OS X machines."

That's pretty disappointing to me, but not unexpected. My bet is that this will slow, to a crawl, adoption of Silverlight by OS X users. While it's true the techno-elite, ADD generation, gotta-have-it-because-it's-new group have adopted Intel Macs en masse. There is a HUGE group of loyal Apple users still happily using their Blueberry and table-lamp iMacs using OS X. Apple's upcoming Leopard release will support PowerPC machines, but no word has come out on how long PowerPC support will continue. I'd love to hear the reasons for supporting Intel only. If I were to put out a SWAG, I'd say it has to do with Endian-ness and byte swapping. But I'd like to think that there is a more intractable problem with moving the CLR/DLR to PPC than just not wanting to write some code.

There are a couple of other facts that have been hinted at but it's nice to see them confirmed by a MS employee.

Silverlight lets you run compiled .NET code in the browser, not just Python and JScript code. Any assembly that has been compiled to target the Silverlight libraries should just work. So if you want to write code in C#, VB.NET or Boo to target Silverlight, knock yourself out.

Which is nifty and not unexpected. That's the whole point of having a Common Language Runtime.

The DLR will also run on top of the desktop CLR V2.0, not just the Silverlight CLR. We have a generic hosting API that lets us retarget the DLR to run on top of arbitrary hosts. Silverlight is only one such host.

Which is a little more interesting to me. I keep wondering if assemblies written against the DLR would be able to run against either CLR. I'm still trying to wrap my head around what MS really means when they say "CLR" in the context of Silverlight. Up until now, there has just be one CLR. It's evolved to support new language features, but the .NET Framework itself has evolved parallel to the CLR. Now it appears that we have two distinct CLR's. CLR Desktop and CLR Silverlight. Are they compatible? If you compile an assembly against one, do you have to recompile to get your assembly to work with the other (provided you use the namespaces available in Silverlight). I think it does.

An interesting side note: So now we have a "portable" CLR. Meaning you don't have to have the full .NET runtime installed on your client machine (at least as far as I can tell) to run Silverlight applications. Silverlight brings it's own small runtime along with it. It would be nice if this option were available to desktop developers as well. Meaning you hit "build" in the IDE, the compiler bundles up the specific namespaces and references that your application needs and puts them, along with the portable CLR, in your build directory. Almost like static linking.

If you are using "Namespaces" to segregate your Javascript code in your Silverlight application, you can't use the nested methods as handlers in your XAML page.

XAML snippet

If you assign the event handlers in your XAML markup, the code won't fire when the XAML element is clicked. You can move the event handlers up to the Javascript global object and then either handle your events from there or call your namespaced event handlers.

The third option is to write up the event handlers programatically. I haven't had any luck doing it this way yet. The best place to do this would be in the control onLoad event, which fires before the page onLoad event. The example template supplied in the 1.0 beta SDK uses this method.

The MS PM said in the forum that this behavior is by design and won't change for version 1.0.

edit: You can't add the namespaced event handlers programatically either. I guess we'll just have to make sure we have unique names for all our Silverlight event handler methods in the global object.

FWIW you don't have to use the createDelegate method used above, you can use the "addEventListener" method like so: