Putting Mix, Silverlight, the CoreCLR and the DLR into context
Updated: I got some feedback from some MSFTies and this is an updated ecosystem diagram. For reference, here's the original ecosystem diagram. This version is better, but still who knows, eh?
I'm over here at Mix. There were some big announcements at Mix07 this year. Many were expected, a few were not. I've been following WPF/E with interest for the better part of a year.
Overheard: "There's a lot of college kids, lotta high school kids out there who expect more things to move." - CEO of MLB.com referring to the increased expectations young folks have while on the web.
I'm off in a corner here at some party trying to put it all into context. For a complete list of links, I'll suggest you head over to Sam Gentile's site.
Most Awesome Marketing-Guy Quote of the Day: "This announcement opens up significant opportunities in both the 'lean-in' and 'lean-back' environments." - MLB Marketing Guy refererring to folks watching MLB.com at their desks, or on their couches.
Here's what was announced in the driest terms:
- Silverlight 1.1 Alpha - All of the above including a CLR 2.0 (Whidbey) compiled CLR and Type System along with select BCL (Base Class Library) classes from the .NET Framework 3.5 (Orcas) including DLINQ. Also included is a new dynamic language runtime (DLR) layer and support coming for Python, Ruby,
- Expression Studio - Design, asset management and interaction design application suite with XAML editing and Visual Studio integration, along with a Media Encoder.
- Silverlight Streaming - More developer focused than YouTube, this service gives you 4GB of free storage and virtually unlimited streaming of video clips using Microsoft's content deployment network. Why? Because Silverlight looks bad if your web host sucks, and if Microsoft hosts your videos, you, Microsoft, and Silverlight all look good.
Some good places to start learning are:
- http://www.silverlight.net - The Community Site
- Telerik's Silverlight Controls (Telerik sponsors my podcast, but the still rock)
- QuickStarts and Samples
- Lutz Roeder's SilverLight Samples
- Be sure to check out Jon Udell's Podcast with Jon Lam where they talk about the DLR (Dynamic Language Runtime).
- Also, once you've installed it, if you run Firefox, put "about:plugins" in the address bar, and note that Silverlight is installed as the "WPFE Plugin."
Now, what follows is just me talking. Not my company, just me and everything here is just my opinion and ruminations.
Everyone who saw the keynote has a different take on what they've seen, and what Silverlight means to them. While the Microsoft messaging was pretty spot-on, I think that some context couldn't hurt.
Silverlight has Flash-like qualities, and Adobe was brilliant to counter the coming announcement with the Open Sourcing of Flex. All this means more choices for me, the developer.
Overheard: "This is the biggest thing since God talked to Moses. Well, maybe not, but it's still up there."
While folks are justifiably stoked about the rich media and interaction benefits of Silverlight, and I don't mean to draw attention away from those good things, but I want to touch on the most game-changing aspects of this announcement while you all are watching 720p HD video over Silverlight and thinking this is a direct shot over the Flash bow.
1. The impact of the new Dynamic Language Runtime should not be underestimated.
This new layer on the CLR adds a number of features around code generation and dynamic type systems that take the CLR's already decent support for dynamic languages to a considerably greater level. This DLR will enable support for Python, EcmaScript 3.0, Visual Basic "10" (VBx - VB as Dynamic Language), and Ruby. Initially this support will be enabled in Silverlight in the browser sandbox, but will no doubt move to the server side soon.
A cool side note; John's team added a subtle nod to the Ruby team in their demo. If you want to access a .NET library, like say, List.AddRange(), when you access it from Ruby it'll be list.add_range. Subtle, but an important (and classy) statement of respect for one of the things that Ruby programmers feel strongly about.
1a. Code for the DLR, IronPython and IronRuby will be released under the Microsoft Permissive License.
This is nothing but a good thing. I look forward to seeing what the folks who use Boo (another alternate .NET language) and the MonoRail and Castle Project guys come up with in to exploit these new dynamic services for their languages and environments.
2. There's a "new" CLR in town, and it's for more than just animation.
During the demo, ScottGu showed a Windows Developer connecting to a "CoreCLR Remote Debugging Service." The text "CoreCLR" appeared briefly in the Attach to Process Window in Visual Studio.
Check out this great diagram of the Silverlight 1.1 world, at right - click for the giant version.
The CoreCLR term refers to the CLR that powers the Silverlight 1.1 Alpha. I like to think of this as a "reimagining" or refactoring of the current CLR. The Silverlight CLR isn't tiny, micro, or crippled. It's refactored, modularized, tightened, simpler with fewer dependencies. This new CLR design will likely power and influence future CLR versions. The diagram above is my own speculation, memory and from Googling around.
Also, the CoreCLR in Silverlight can live in the same process space as the existing CLR. So if Internet Explorer has a .NET plugin or toolbar loaded, Silverlight keeps working fine.
2a. You can use and re-use existing .NET assemblies, business logic even, in Silverlight
The assembly format is the same - it's the same CLR - so things that you've previously used on the server-side and potentially (depending on the libraries in the BCL you used) reuse them on the browser-side and finally put all these Core2Duos to work doing more than just waiting for <angle brackets to show up> for rendering.
2b. It works on a Mac. Same binaries, no cross compilation, just IL, working cross-platform.
The Mac version of Silverlight is a Universal Binary and runs the same code and renders the XAML exactly the same on the Mac as it does on Windows. There's also, as mentioned before, support for debugging Silverlight client apps running on a Mac directly from within Visual Studio.
Overheard: "It's the new smart client. It's a chubby client. Everyone knows chubby girls are smarter."
One great prt of the demo was done entirely in TextMate on a Mac where ScottGu created a Silverlight XAML file and CodeBehind in IronRuby. There was no Visual Studio or C# to be seen. The potential for Silverlight to energize the LAMP stack and complete with mXml is great. Silverlight might be the only Microsoft technology in a solution. Everything can be served by any Web Server as long as the mime-types line up.
3. Your XAML can be used all over.
One thing to know about the XAML rendering that's happening on Silverlight is that it's a different XAML parser/renderer than the one included in WPF.
If you're on Vista, try this cool test. Open up the Accessibility Magnifier and hover over any WPF app, like the New York Times Reader. Rather than little raster/bitmaps becoming large raster/bitmaps, you'll see beautiful scaled vectors. As long as what you're looking at is a XAML vector rendered on Vista with WPF, you can scale it forever.
I speculate - I haven't tried this yet - that if you put the Vista magnifier over a Silverlight XAML-created vector I suspect you'll get a scaled bitmap, not a smooth vector. This is because Silverlight will run on a bare-naked Windows XP (not even SP2) machine, and Silverlight's XAML renderer is painting via GDI. This is not a huge bummer, but it's a significant and very clear, visceral way to illustrate that there are two XAML renderers. Fortunately XAML is a clear spec, and both WPF and Silverlight (on both platforms)should both render identical XAML identically. It's not open to interpretation the way that HTML was/is.
Overheard: "This is the most significant launch since .NET 1.0 and I don't think 10% of the audience gets that."
I'm pretty stoked about this whole thing, and I'm going to dive into both Silverlight and Flex, along with other options like OpenLaszlo as there's many ways to create a Rich Internet Application these days. The addition of an integrated client-side CLR will allow for greater scalability in large systems where the server is called upon to do calculations that really belong on the (increasingly powerful) client-side.
<disclaimer>I don't work for Microsoft, nor is any of the data on that diagram from NDA'ed sources. It's very likely wrong, so enjoy.</disclaimer>
I may also have overheard myself saying all those quotes, but one can't be sure about these things. :)