Silverlight and the DLR

Microsoft has announced that it is embedding a version of the CLR into their Silverlight RIA technology. Blogging machine Ryan Stewart had some of the initial details, and Sam Gentile has a good pile of links. The CLR enabled version of Silverlight will run inside Firefox (both on Windows and OS X) and inside Safari. This is a good step at cross platform support, but the omission of Linux, while not surprising, reduces the reach of Silverlight versus Flash or regular AJAX. Also, it appears that there are no Mac development tools for Silverlight, although presumably there is always text editors.

DLR
The most interesting part of the whole business is the Dynamic Language Runtime, which is the project that Jim Huginin has been working on since he arrived at Microsoft. The DLR currently supports JavaScript, a dynamic version of Visual Basic, IronPython, and IronRuby. John Lam’s work at Microsoft also appears to be paying off. eWeek had three good articles on DLR technology, and all three articles include conversations with Jim and John. It’s nice / interesting to see that two people could have a large impact on Microsoft. The DLR is being made available under a BSD style license. While I have to give props to Microsoft for choosing an unrestrictive license, I’d point out that a license is not a governance system, and while the DLR might technically be open source, the “Core CLR” definitely is not, and neither is the XAML portion of the Silverlight runtime — no surprise there. I wonder if we will be seeing a port of the DLR on top of Mono. I also wonder if IronRuby can run Rails, although that seems like a weird thing to want to do inside of Silverlight.

Linq
Another part which I find interesting is the inclusion of Linq as part of the Core CLR. I like Linq, and if Microsoft is going to try to define a new platform for inside the browser, I’m happy that they’re including Linq as part of the core.

Impacts
Here are some of the potential impacts of this announcement:

Since Silverlight will include the CLR, it will benefit from the CLR JIT and garbage collector, which together with Mozilla’s Tamarin, will raise the bar for JavaScript performance in the browser. It’s unclear whether regular AJAX apps running in a Silverlight enhanced browser would beneft from CLR acceleration of Javascript. I’m in favor of the browser vendors getting into a Javascript performance race with each other.

Allowing people to write browser side applications in multiple languages fragments the technology on the browser side. You could argue that the benefits of either IronPython or IronRuby are sufficiently large over Javascript that such fragmentation is ok. I’m not as sure that this is a good thing.

If there is significant uptake of IronPython or IronRuby for Silverlight development, that could have interesting impacts on the Python and Ruby communities. The Ruby community is already dealing with a proliferation of different Ruby runtimes, so there probably isn’t much new there other than a change in the mix of adoption of the various runtimes. On the Python side, its less clear, since the CPython implementation is the most heavily used.

The inclusion of facilities like Linq will boost the semantic level of the platform running in the browser. Granted, it only does that for Silverlight, but I hope that this puts some pressure on the other players to provide more leverage in the platform. If we are going to be building much richer applications inside the browser, we are going to need all the help that we can get.

So what?
In the end, though, I probably won’t be doing much with Silverlight, for the same reasons that I’ve written about before. The technology has definitely gotten stronger, but the other issues haven’t really changed much: there are no tools for the Mac or Linux, and as far as influencing the technology, you’re just standing outside the Big House, pressing your nose up against the window.

11 Responses to “Silverlight and the DLR”


  • In reply to your ‘so what?’ statement — how about this bold prediction: http://buytaert.net/linux-on-the-desktop ? It’s far from the current reality, but this might be an important baby step that sets a number of things in motion. Or not. :)

  • Hi Ted,

    I would be very surprised if IE’s JScript engine were replaced or somehow accelerated by a faster one in Silverlight, if that plugin were present. MS seems not to want to improve JS in the browser from what I can tell, under cover of fear of making incompatible changes. They should feel free to shock me with good news, and of course they may feel competitive heat to improve JScript in IE, at some point.

    It’s good to see more open source, even though as we both have blogged recently, licensing and publishing are just first steps that do not determinte good governance. I wonder whether patches retargeting IronPython and IronRuby to Tamarin would be welcomed? ;-)

    /be

  • PyXPCOM already exists, and this might encourage Mozilla to enable it by default in Firefox. It probably needs some more work to make it truly equivalent to JavaScript for writing webapps.

  • Dries,
    Actually, I think that line of thinking leads to something like an appliance that basically runs a browser as an the only applicatiion.

    Brendan,
    One can only hope…

    James,
    PyXPCOM is being funded by Mozilla, last I understood. Brendan can probably fill in the blanks.

  • Could the DLR be considered as some kind of Parrot for .NET? As for the Ruby community, this thread is an amusing complement to observations about dealing with multiple runtimes:

    http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/0d8580112ca8a73d

    I wonder if Sun can be bothered to respond with some kind of Java platform initiative of a similar nature.

  • Ted: yes, and Linux might be ideal for that. :)

  • My understanding is that pyxpcom is chrome:// only. I haven’t seen it as a standard browser language on the roadmap. Is there a plan to sandbox other languages? Oh how I wish there was…Brendan?

  • Maybe I’m just being simplistic, but it seems that they just want things to happen on their platform, and its a nice one at that. Remember when they realized that the Web browser was becoming the new platform? Well, now its possible to deliver “rich” apps using either JS/XHR and/or Flash (and soon Apollo). They understand that keeping their platform under things will allow them to make money off it one way or another. Keeps their dev’s from migrating away to non-MS technology too. Adobe understands this as well I think, hence the “shared source” approach.

  • Thought this might interest you: Miguel de Icaza (of Novell and Mono) says Silverlight will be available for Linux by the end of the year.

    Silverlight on Linux? We’re in, says Mono founder

  • Not only will the DLR and Silverlight run on top on mono by the end of the year, but I am sure we can count on MonoDevelop to fill the development gap on Linux and Mac!

  • See my latest blog entry. PyXPCOM integrates CPython which has no stable ABI or distribution on Windows. It’s good if you can provision the C runtime and you need the extensive library code. But with IronMonkey, we’re going for memory-safe VM-hosted language support on top of Tamarin.

    /be

Leave a Reply