With the announcement of Silverlight 1.1 on April 30th, the big news in my world is all about the CLR in the browser. In a previous post I talked about what a watershed moment this integration represents for web development in general. I have to emphasise that the ability to render eye-candy graphics is not the root of my excitement. It is the ability to truly deliver RIAs on the browser with .NET, period.
One of my almost immediate follow up questions was how vanilla HTML would work. You know, the equivelent of flipping the "ugly" switch. The ability to write plain 'ol HTML is important because I don't think the average developer is going to be any good at designing Silverlight UIs. I know I won't. I mean, my buttons might be Silverlight and I might have some cool transforms, but unless I get some good assets to play with, my apps will be ugly unless I invest some real time in learning some design skills. The latter is unlikely because my focus is in other areas of application development.
It turns out that there is a bridge between the CLR and the DOM, and it is via the System.Windows.Browser namespace. The HtmlPage class represents the entry point into the DOM and exposes various properties and methods for interacting with the browser. On the surface, this sounds strange, doesn't it? The idea of interop between Silverlight and the browser. But it makes sense, the CLR is a self contained runtime that has no direct communication link with the browser. I imagine that this namespace will become more and more sophisticated as it plays the key role of bridge between the CLR and the browser. Mike Ormond has a good brain dump on one of the Silverlight programability sessions which is quite accurate: http://blogs.msdn.com/mikeormond/archive/2007/05/01/net-for-silverlight-some-features.aspx
What about networking? This is an interesting topic because as much of a step forward that putting the CLR into the browser is (revolutionary, really), I can't help but feel that we have taken a couple of steps back. For example, ASMX/WCF plumbing isn't quite there yet (but will be I'm told) so instead the option is to resort to XML HTTP POST semantics or, as an interesting trick, use JSON serialization to do WS-BASIC Profile I Web services. I thought we had moved beyond JSON years ago, but it does work. All of this is handled in the System.Windows.Browser.Net namespace. The ability to do both synchronous and asynchronous calls to the cloud are fully supported and this is HUGE since the HTTP protocol all but precluded callbacks on an ASP.NET application unless you wanted to do XMLHTTP or AJAX.
Also of interest is the fact that LINQ is fully supported which I see as positive, but it could also encorage bad habits. I don't want to see LINQ code in UI, but there is nothing to say that we can't put a UI Process layer in Silverlight. This is a common layer in architecting ASP.NET apps that do a lot of databinding, paging, etc. The idea is that a lot of this code is re-usable, so put it in its own class and have the UI use it as helper methods. This is the right approach IMO, but I am sure we will see direct LINQ manips right in the XAML code-behind but that is what code reviews are for, right?