 |
|||||||||
|
|||||||||
|
|
Lately there seems to be a lot of buzz around the whole Flex, Flash, Apollo environment for creating extremely powerful, cross-platform RIAs (Rich Interactive Application). In the interest of fairness and objectivity, I've been reserving judgement until I got a chance to really play more with Flex. Likewise, I hadn't really made any judgements about WPF/E yet, either.
So, when I read today that Microsoft had changed the name of WPF/E to Silverlight, I got a little excited. Why? Because by changing that name, it sounded a little bit like Microsoft had finally decided they were going to throw down the gauntlet and try and compete directly with Flex.
I went and saw that Microsoft had re-skinned their WPF/E developer page and it was now called the "Silverlight Developer Zone" , which looked promising. Even more interesting was that there was now a download for the February CTP of WPF/E for the Mac. This looked really good, so I grabbed the CTP for Vista, grabbed the SDK, grabbed some samples and started to look around.
This is where I threw my hands up in disgust. What in the holy name of Scooby-Doo are those people thinking?!?! After poring through the API, I thought "I must be mistaken. Surely this is a mistake." But then I asked a colleague and he confirmed it for me. Let me skip a couple lines and highlight this so you all can see it clearly.
WPF/E (Silverlight) HAS NO SUPPORT FOR BINDING TO MODELS, BINDING TO DATA, OR EVEN CONNECTING TO NETWORK RESOURCES TO OBTAIN DATA.
So, I will summarize Microsoft's efforts to date around Silverlight. They have created a declarative programming model that uses XAML as an instantiation language for rich 2D (not 3D) content and animations, as well as extended JavaScript to support this model. Using this model, you can create embedded mini-apps that have access to rich animations, graphics, audio, and video objects. However, these mini applications cannot communicate with the outside world, they cannot consume web services, and they cannot bind UI elements to data. In addition, this model doesn't even have support for things that should be considered a stock part of any library such as buttons, checkboxes, list boxes, list views, grids, etc.
In short, unless my findings are incorrect, Silverlight, as it stands now, with no support for data binding, service consumption, or basic UI controls, is a worthless steamy pile. I just took a huge step in Flex's direction.
"However, these mini applications cannot communicate with the outside
world, they cannot consume web services, and they cannot bind UI elements
to data."
I suspect at MIX they will be shipping a .NET version of Silverlight that
has a controls encapsulation model.
I couldn't agree with you more, Kevin. I've been working a lot with Flash
lately, and "Silverlight" has nothing on it. I'm hoping that the upcoming
beta release will be a big improvement, but I'm doubtful that it will be
enough. I blogged some more detailed thoughts here: http://devlicio.us/blo
gs/rob_eisenberg/archive/2007/01/30/net-3-0-crash-course-part-8-wpf-conclus
ion.aspx
Once they put the mini-CLR behind it, you are now talking about a 2MB
download footprint, and you're getting closer to a model that can be
compared with Flex. however, I'll believe it when I see it.
My claims refer to the lack of ability to DATA BIND. The Downloader object
in the SDK is a pure-functional component. In other words, in response to
some event, it can make an outbound HTTP connection - but you'll note that
the outbound HTTP connection is limited by the same rules as other
JavaScript on a page - e.g. source host communicaiton only. If Microsoft
has fixed this, then they haven't shown it in any documentation.
Apparently some people seem to think that because I didn't mention the
Downloader component, I didn't do my research and my complaints about
Silverlight are baseless and unfounded.
In response to your Silverlight article. First off, as far as databinding
> sure its by hand, but functional calls to webservices allows for in
browser based networking. The downloader resources allows pulling of
asynchonrous data ( images, videos...). If you need to right click and
databind > well you shouldn't be posting articles.
If you look at the original article, I was talking about Silverlight 1.0,
the piece of Silverlight that didn't have any CLR support in it.
Silverlight 1.0 offers very little in comparison to Flex & Flash. I've been
using Silverlight 1.1 for a while now and I find that, while it feels
awkward to have to draw everything in terms of canvases and feels very
basic, there is also a lot of real value in Silverlight.
