Silverlight doesn't *need* http capabilities

Jeff Atwood's just taken to task some bloggers that haven't done their homework. Personally, I'd have taken them to task for writing in all-caps bold, but that's just me.

I know this is completely orthogonal to Jeff's point, but I'd like to tackle the Silverlight complaints. These were simple - you can't download from a Silverlight control, and there's no databinding or controls. The latter one I can't argue with (although there are hints that there will be a large announcement at mix07 - I'm thinking either controls or tiny CLR support), so let's look at the first.

Saying that Silverlight can't make http requests really misses the point. As Jeff points out, it does actually support a "downloader" object that is very much like XmlHttpRequest; it just adds progress notifications. Ok, that solves the problem, but it ignores the bigger picture - the reason Silverlight is not your traditional browser plugin.

Compare it to Flash (but not in the obvious way). Flash is (mostly) very self contained. You create a .swf file that contains graphics, sound, layout and script. It uses the capabilities of the Flash virtual machine to do anything it needs to do. Silverlight approaches this from the other direction. You give it a loose XML based XAML file. Silverlight downloads whatever resources you reference in it. If you want any logic, you write Javascript in your page, not in the control. You want to download more stuff? Use XmlHttpRequest.

This is a brilliant, simple and very effective idea. We've seen huge advances - and takeup - in the use of Javascript and XmlHttpRequest. Why reinvent the wheel?

Silverlight's secret weapon is its browser-scriptable object model.