Tag Archives: silverlight

Silverlight and the DLR

17 Replies

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.

Why WPF/E didn’t make my cut

10 Replies

Dare Obasanjo thinks that WPF/E ought be included in the list of contenders for RIA foundation. He makes his argument on the basis of some technical criteria (which I agree with). He also says that being open has nothing to do with it, and cites Java and Visual Basic as existence proofs that a single vendor technology can rise to the top. I never disputed the fact that a single vendor solution could rise to the top. That was the point of my original post. However, and unsurprisingly, I disagree that openness is irrelevant to the popularity of RIA platform technology, especially since part of the point is to deliver solutions that run on all the platforms that today’s web applications run on. And ultimately that’s why I left WPF/E off my list, even though I’m sure it’s on other people’s.

Miguel de Icaza followed up Dare’s posting with more analysis on WPF/E, Flash and the openness of Java. He does have some slightly out of date information, since the recent versions of OpenLaszlo no longer require a server, even when Flash is the runtime. You should read Miguel’s post for his analysis of the openness of Java. He’s right that the JCP process did help get other parties involved with the future of Java, which did ultimately help it. He’s also right that the JCP brought us nightmares like J2EE (I’m not as sure that you can blame the generics mess on the JCP). I would point out some JSR’s also came from the open source community, not just from companies. Not only that, EJB3, which puts to right a number of the worst problems with EJB2, borrowed heavily from ideas that first appeared in Hibernate and Spring, both open source projects. In any case, as I pointed out in my followup posting, I’d hope that we could do better than both the W3C or the JCP for Flex/Flash or OpenLaszlo.