Today I was at the Microsoft Remix07 event in Milan, where I attended a detailed introduction to Silverligth. The remix is a sort of "local repeat" of the key sessions at MIX, although with different presenters, I guess. Here were a bunch of tech evangelist, not the actual R&D people... but I liked the event, and appreciated I could drive there in 50 minutes... quite different that getting to Las Vegas.
I was at the keynote by Keith Smith and at two back-to-back sessions by Ernie Booth. Than sat for the initial part of a Visual Studio Orcas talk... but felt it was not really worth to me and got back home. If the keynote provided an overview of the Web-related technologies Microsoft, the Two sessions on Silverlight were very nice, even though not very in depth. The key point was to discuss Silverlight integration with .NET, but let me clarify a few points for everyone (hoping I got them right), first, as some readers of this blog might not be familiar with what's been announced by Microsoft in recent weeks.
- Silverlight is the name (and a nice name, not another crappy 3 letters acronym) of what was previously known as WPF/E, Windows Presentation Framework for everyone. Now in case you have been on the moon, WPF (previously Avalon, you see a nice name turned into a bad one...) is a relatively new visual foundation for writing windows applications. Part of Vista and partially available on XP, it is based on DirectX to add a rich multimedia and graphical experience to Windows client applications. But I'm digressing....
- Silverlight is for Rich Internet Applications, or rich browser-based applications. That is, it competes head-to-head with the Flash player.
- Differently from WPF, Silverlight doesn't need DirectX and the latest and greatest GPU (like Vista) but works across many versions of Windows, and even on the MAC and even from multiple browsers (including Firefox, which was used for many demos... and mentioned as a faster JavaScript processing browser).
- Like in Flash, a lot of focus in Silverlight is on audio and video streaming, something plain JavaScript certainly falls short with. Quote "Video is very important for Silverlight". They got to the (very interesting) point of providing a free streaming service on silverlight.live.com, where you can host the videos for your web applications (size and bandwidth limits seems good enough even for serious use).
- There are two different versions of Silverlight coming. Silverlight 1.0 will be a collection of Javascript modules capable of rendering Microsoft's XAML (or a subset of it, as few controls will be available) in a browser. Silverlight 1.1 will be a reduced-footprint .NET CLR delivered in the browser and running in a sandbox. This is a little confusing. The first versions should be out int he summer, no dates have been given for 1.1... which looks really like a 2.0 versions to me, but numbering/versioning of technologies seems to be very odd at Microsoft these days.
I noticed some interesting ways of "reality tweaking". First, they refer to their 3 platforms (web, desktop, RIA) but I think there isn't a clear cut distinction between web and RIA. Second, the desktop platforms is made of WPF applications and Office enabled apps. WinForms and traditional Win32 apps are out of the picture, which I find amusing. Another element is the fact they are releasing a JavaScript-based solution (Silverlight 1.0) and they are bashing it (along with JavaScript) at the same time. It used to be that last year Microsoft stuff was bashed by Microsoft to sell the new version. But downplaying something that is still in beta because next year solution will be so much better is superb!
The sandboxed Silverlight client will certainly make people confident about using those web applications. Still, the need of a file upload mechanism to let the client application see a file is a little beyond my expectations. Anyway there sill be no "elevation", no way to get out of the sandbox for security reasons.
Another interesting element is the size. The presenter talked about a 50 MB size for the .NET runtime against an expected 4 MB size for the .nET in Silverlight 1.1. Was he exaggerating to prove his point? You generally hear about a much smaller size for .NET from its evangelists... I wonder who is right. Anyway, 4MB looks small but it is over 4 times the Flash runtime, if I'm not wrong and is already cutting some people with slow connections off.
The other big problem with a reduced footprint for the .NET runtime is that they had to cut off many features. Possibly too many features. Yes, answering to my question on this topic Ernie mentioned that there might be extra modules to download with more features, but this looks one of the big problems ahead. For example, I noticed a significant limitation in XML-support. You'll apparently have XmlReader and XmlWriter, but no full DOM and no XPath. Considering that XPath for processing XML Ajax request is supported in JavaScript libraries totally under 40 KB, I wonder if Microsoft approach makes any sense. Having to parse a document (with hand-written code) only to grab some limited data looks quite dumb (even if the code, compiled, will be fast). Not only XML support but also HTTP / networking support looks limited. Silverlight piggy-backs on the browser connectivity using the new BrowserHttpWebRequest class (again, mostly for security reasons) and you'll be able to talk back only to the hosting servers (like in AJAX callbacks). Even if RESt was mentioned (and partially demonstrated), the main focus remains on SOAP. No sorry, the native SOAP language bindings won't get my vote over XPath support!
Some of the demos looked very nice. I particularly liked the ability to load a XAML file and instantiate it dynamically, hooking back to the generated controls by means of a FindName call (like a dynamic FindComponent in Delphi). Well, I found it very similar to the loading of a DFM stream... but doing this in the browser is nice.
There was much more int he talks (and in Silverlight). It will support LINQ (well, with limitations at first). It has an interesting two-way HTML integration (with .NET code that can access the browser's DOM and JavaScript that can use "exposed" .NET objects), which puts it way ahead of Flash (from what I know). It has/will have support for dynamic languages, so you'll be able to use Python or Ruby to code the client side of your Silverlight system.
Did I mention the limitations? With a whopping 6 controls (not even radio buttons, sorry) the current alpha version is certainly nothing more than a tech playground. Many features are under development. Many under consideration. The presenter suggested the rule "no production applications on the Silverlight alpha". Production on an alpha? Even thinking it scares me.
I even got a glimpse of extension methods, which look very familiar to me... the syntax is quite different from Delphi .NET class helpers, though.
Anyway, from the presentations and demos (not having played with the technology myself), I'm quite impressed with Silverlight. It is so different from what Microsoft has done so far. Yes, it is a Flash clone, but there is a lot of value in it. And development tools support looks quite good, as Microsoft is putting a lot of effort in it. On the other hand, the strategy is confusing. You have Windows Live programming (and Vista gadgets) in almost pure JavaScript, you have AJAX support in ASP.NET, you have two different versions of Silverlight, plus WinForms and the (still relevant?) WPF. 6 user interface models seem a little too many, even from a software giant like Microsoft...
If all this sounds a little confused, it is because I am a little confused... feel free to help me get the missing bits!