The big news from last week's MIX07 conference all surrounded Microsoft's new Silverlight browser plug-in for creating rich internet applications (RIA). The two things I'm most excited about are the integrated Common Language Runtime (CLR) within Silverlight 1.1, and the new Dynamic Language Runtime (DLR) for .NET, both announced and demonstrated for the first time at MIX07. More on both of these topics later in this blog entry.
While many bloggers and journalists have focused on comparisions between Silverlight and Flash, I honestly don't know enough about Flash--or even Silverlight, yet--to be able to contribute to that discussion from a technical perspective. But based on what I've seen and read so far, if I had to speculate on the market impact of Silverlight, I'd make three guesses:
- the majority of people who currently use Flash will probably not flock to Silverlight, but will continue to use the Flash tools and technology they've invested in and are familiar with;
- some people who currently use Flash will begin to experiment with Silverlight, but will use Silverlight in addition to Flash, not as a replacement; and,
- there are many, many companies and organizations who currently don't use Flash at all, but who will begin to look at Silverlight for RIA development.
The bottom line is I expect to see significant adoption of Silverlight--particularly by Microsoft shops--but not necessarily a diminishing use of Flash as a result. Both Flash and Silverlight are probably here to stay for the long term.
Silverlight is a cross-platform, cross-browser plug-in for displaying rich multi-media user interfaces. "Cross-platform" is currently Windows and Mac OS X Intel (not PPC), though there is talk of a non-Microsoft open source implementation for Linux by the same people who created Mono (an implementation of .NET for Linux). "Cross-browser" is currently IE, Firefox, and Safari, and future support for Opera has been announced by Microsoft. At all of the sessions I attended, the presenters made sure to show all of their demos running on both Windows and Mac on a variety of browsers.
Finally, Microsoft announced the Dynamic Language Runtime (DLR) enhancements to the .NET CLR. These enhancmenents apply to both the "full" desktop/server CLR and the version integrated with Silverlight 1.1. The DLR is derived from work on the IronPython, an implementation of the Python programming language for .NET. The idea of the DLR is to provide a common support layer for implementing dynamic languages on .NET. Microsoft showed demonstrations of IronRuby--an implementation of Ruby for .NET based on the DLR--as well as DLR-based implementations of JScript and Visual Basic.
Hmmm...are there any other dynamic langauges that might be candidates for implementation on the DLR? What about CFML? "IronDragon" anyone? What might a DLR-based CFML implementation look like and allow you to do that you can't currently do? Imagine being able to do things like:
- compile CFML code into .NET assemblies (.dll)
- have CFCs subclass (inherit from) any .NET class written in any .NET language (C#, Visual Basic.NET, IronPython, etc.)
- have .NET classes written in any .NET language subclass (inherit from) CFCs
- be able to use CFML anywhere you can use C#, Visual Basic.NET, etc., to create any type of .NET-based application
- create AJAX-style applications running CFML within the browser (within the CLR integrated within Silverlight 1.1)
- have IntelliSense and debugging support for CFML within Visual Studio
We've all heard the phrase "CF is Java" and while I recognize the underlying truth this phrase is intended to convey, I've always been bothered by a fundamental "untruth" in this phrase. CF is not Java in that writing CFML code is not the same as writing Java code. "CF is Java" is basically a marketing phrase that hides as much technical truth as it reveals. It's probably more technically accurate to say "ColdFusion is a Java application" (or, "BlueDragon is a Java application"), but also that "CFML (the programming language) is not Java."
With the DLR, I think there's an opportunity to say, "CFML is .NET" and mean it in the fullest sense. There's an opportunity to make CFML a "first class" language for .NET, fully equivalent to and interoperable with C#, Visual Basic.NET, IronPython, IronRuby, JScript, etc. In other words, writing CFML code for .NET would be the same as writing code in any other .NET language. It's this opportunity, along with possibility of running CFML code within the browser (within Silverlight) that has me most excited.
I'm going to Redmond the week after next (May 21-23) to work with the DLR team to learn more about what they've done and how we might create a DLR-based CFML implementation. I'll post more information as I learn more, and hopefully we'll even have something to demonstrate at CFUNITED-07.
P.S. Here's a must-read blog entry by Scott Guthrie that talks about Silverlight, the embedded CLR, and the DLR in more detail.
May 12 UPDATE: after digging through the DLR for the better part of the day today, I'm even more excited about what I think we're going to be able to accomplish, and how quickly. It looks like one additional benefit I hadn't thought about is the ability to create and invoke CFCs from other .NET languages using the native syntax of that language. For example, you'll be able to create CFCs from C# using the "new" operator rather than having to rely on a JavaProxy-like implementation. This illustrates the "deep" level of integration we'll be able to achieve with .NET via the DLR versus current CFML implementations on .NET or Java.