I had the privilege of giving a talk last week at the Triangle .NET User group on the topic of Ruby and the CLR. My talk was prepared well in advance, and was going to go into detail about RubyCLR and its place in the Ruby runtime universe. Then, of course, at the beginning of last week, the world shifted under my feet at Mix07 when John and Jim announced Silverlight, the DLR and IronRuby.

At the meeting, Chris Love gave a 15-minute talk before I got up, all showing samples of Silverlight in action. (Thanks, Chris, for the kind words, by the way). Chris did a great and enthusiastic job, but he said something then that I've since heard repeated and I'd like to talk about. He said, approximately, "Here's Silverlight, and it has just killed Ajax."

h2. Silverlight vs. Ajax

The general thrust of this argument is that having a full-fledge rich-windowing experience in the browser is going to put a stop to all that amateurish mucking around with JavaScript and the DOM. I said it at the meeting, and I'll say it again here, that's hogwash. First and foremost, there will always be a developer community whose members will not adopt a technology that is a) closed source and b) under the control of a single corporate entity. Anybody who ever used the acronym LAMP in casual conversation is a member of this group. They simply will not base their technology stack on Silverlight, or Flash, or Flex, or JavaFX, or whatever.

Which means that, to the extent that Chris and others are right, they may be right that Silverlight will kill off Ajax development within the current Microsoft development community. That's probably true, but only to a degree. Silverlight currently runs only in IE and Firefox on Windows and Firefox and Safari on the Mac. (From what I hear, Opera for both platforms is "close".) There are two platforms missing from that list: *nix and the loose collection of OSes known as mobile devices. Development teams will still need to support those clients, so Silverlight won't just nix JavaScript and the DOM overnight.

More importantly, if the message of Silverlight is "write rich desktop-like apps and deliver them in the browser", then Silverlight isn't going to kill Ajax. It is going to kill ASP.NET. Why even have a stack whose purpose is to translate big, functional, object-oriented code into some combination of HTML and JavaScript if you can just whip up some slick XAML and get cool features like local storage to boot? If Silverlight is the future, then necessarily, ASP.NET is the past. I don't see many people talking about this. Sure, there are a ton of articles about creating Silverlight controls for ASP.NET apps, but really, why not go all the way? Which brings me to my next question….

h2. Silverlight vs. Flash vs. ClickOnce vs. Web Start vs. XUL vs. Applets

Remember when applets were the future? And the browser wars of the mid-90's were supposedly because Microsoft was afraid that Netscape Navigator would replace the desktop? Remember when Flash represented the future of the UI? Or Web Start and ClickOnce would bridge the gap between the rich desktop experience and the ease of deployment of the web? Yeah, me too. And exactly 0% of those things came to pass. Applets died and left the world with nothing but a gymnastic Starfleet insignia. Navigator bought it when IE became "free" as in "monopoly". If the state of XUL can be inferred from the state of XULPlanet, then XUL has been visited by the Borg. Web Start was too slow, and ClickOnce was just another way to launch a Windows installer but without all the, well, windows. Flash has become the game/media player/cartoon/hip banner ad technology of choice, but how many of us have actually used an application developed in Flash? (Other than Rich Kilmer).

So what does Silverlight have that the others don't? At first glance, it is just the Flash model. Except, its the Flash model with multiple possible languages with which to write your code. So you get reach, rich controls, browser interaction, access to extra-browser capabilities, cross-platform deployment AND your choice of C#, VB, JScript, IronPython or IronRuby to author your apps. The downsides seem to be Microsoft dependence, lack of *nix support, lack of Standards (meaning minimal third-party ability to create more deployment vectors), and the Microsoft Permissive License (worst legal document name EVAH…sounds like something from a swingers' club).

h2. What about JavaFX?

So, Sun immediately comes out with its answer to Silverlight, called JavaFX. It seems to be an unimpressive, needless alternative to Groovy (I'm not alone in thinking this. It has no coherent deployment story, other than the JavaFX Mobile platform, so it at least hits a niche Microsoft missed on its first swing. I think I'll just stick with Groovy, thanks. Or JRuby. Or Jython. Or anything that doesn't have this lame q/a in its FAQ:

Why isn't Groovy enough? Groovy and other languages have two specific traits which don't precisely meet these needs, namely that they are generic in nature and don't provide the appropriate abstractions necessary to optimize the UI design process and similarly are designed specifically for programmers other than content authors.

I mean, c'mon. Even if you leave aside the actual SwingBuilder libraries and other downloadable UI layers for Groovy that already exist, the entire POINT of a language like Groovy is that it is flexible enough to write those abstractions your own damn self. That reasoning is beyond flawed; its written by a salesman, who doesn't have the faintest idea what Groovy is, or why anybody would use it. Which brings me to point #4….

h2. The DLR

When you hear Microsoft people speak of Silverlight, they will often mention the DLR (Dynamic Language Runtime). This is the layer that replaces the IronPython bridge and RubyCLR. They've created a common type system for a variety of languages, including JScript, VB (the way it ought to be), IronPython, and now IronRuby. It then provides a bridge between this dynamic type system and the standard CTS. It currently runs in Silverlight, which means it will let me write my in-browser code in Ruby, which makes me happy.

In fact, I'd argue that the DLR was my favorite attempt at a new runtime for Dynamic languages except for two small items: first, the team has gone and written its own spec for dynamic type systems without really playing with the other kids on the block. Charles Nutter, for example, has been leading the charge on creating a real spec for Ruby, and Microsoft pretty much sidestepped the whole thing. The second issue is….

h2. Microsoft might be the lamest company in existence.

Microsoft recently announced that it believes that up to 235 of its patents have been infringed by FOSS. They are laying the groundwork for a culling of the herd; they are threatening legal action, hoping that the weakest of the FOSS vendors will crawl into Redmond and pay tithe so they won't have to go to court over the issue. Microsoft really doesn't want to go to court. They've already beta tested that option by sponsoring SCO. No, Microsoft just wants to spread the FUD and pocket the low-hanging fruit. I'm with Tim on this one.

All of which means that, if Microsoft is going to go and adopt open source technologies to make their platform better, while distributing their own code under what can best be described as the Nixon-mask version of an open source license, and then spread FUD grenades around in the crowded marketplace, then their dynamic platform has very little real chance of being adopted by anybody outside of Redmond.