Soooo, ok, they released a new May CTP of ASP.NET AJAX futures. It's got some new support in there for Silverlight related stuff now. Great, awesome, love to see it and totally understand they need to pimp the new platform. What has really happened beyond that though? I'm not seeing (m)any differences in the xml-script, bindings, controls and animation code that (used to?) make(s) up the real power of the previous release of the futures.

As a simple example, let's start with the fact that there's no standard ICollection interface. There's INotifyCollectionChanged (weird considering there's no ICollection, eh?) and there's loose support for duck typing of a collection class within some of the controls, but no true ICollection yet.

As a more complex example at the Selector control. First off it's data-binding support is weaker than that of ListView. Selector can either take a "pure" JavaScript array of objects, which it wraps with a DataTable (heavy handed), or it can take an instance of an object which is parses using parseFromJson (bad name if you ask me... JSON is the serialization format, not the runtime representation of the object) and, again, turns it into a DataTable. ListView on the other hand supports that concept of a custom collection (through duck typing as I mentioned above). Selector also doesn't even expose a way to get at the currently selected item. Sure it gives you the selected index, but that's extremely useless in binding scenarios which is the most powerful feature of the futures. We actually extended the prototype of Selector here at Mimeo to support  the above shortcomings in anticipation of it being added in the next drop. If anyone else wants these enhancements, click here to download.

Even further still, DataSource doesn't properly support custom WebServices (i.e. Sys.Preview.Data.ServiceType.Handler). Neither does ServiceMethodRequest. which always wraps the parameters as DataService parameters (i.e. parameters + loadMethod), so we can't even call our own web methods using it without creating a shim method on the web service likse MySearchHACK(Dictionary<string, string>, string) and then converts the parameters and calls the real method which is MySearch(string, int).

Anyway, it seems like Silverlight is ursurping the development of the core AJAX futures and, while I'm all for Silverlight, I think it's a bad move to put these features on the backburner. They should be fleshed out and delivered. They are extremely valuable to those of us trying to build rich web browser (only) based applications.

I'd love to hear from someone inside MS on what exactly their intentions are at this point. If it's dead, fine... just let us know. If it's not, tell us what to expect and when to expect it so we can make decisions on how to proceed. I've said it before and I'll say it again, the stuff that was cut from ASP.NET AJAX 1.0 and ended up in the futures was much more important to developing rich internet applications than 1.0. It's true that 1.0 layed the groundwork, but having to cobble together all the UI in JavaScript still with $get and $addHandler, while possible, isn't what I'd call a good platform. I want to do:

<page xmlns="....">
  <serviceRequest id="myWebServiceRequest" url="MySearch.asmx" methodName="Search" useGet="false" />
  <textBox id="mySearchText"/>
  <button id="myButton">
    <click>
      <invokeMethodAction target="myWebServiceRequest" method="invoke">
         <bindings>
            <binding dataSource="mySearchText" dataPath="text" property="parameters" propertyKey="searchText" />
         </bindings>
     </invokeMethodAction>
    </click>
  </button>
</page>

Declarative, simple, no code. That was the power of ASP.NET AJAX before the split and hopefully remains the power when (if?) the futures are ever truly delivered.