At last Microsoft has released an early build new AJAX libraries based around version 2 of their .NET Framework.
Skip this next section if you are already familiar with what AJAX is and don't want to read my lame ass description of it.
The most basic intro to AJAX…
Typically at the core of any AJAX library we see something along the lines of first creating an instance of the ActiveXObject "Msxml2.XMLHTTP", and then using it to make the calls back to the server, asynchronously. Don't be afraid when you see "MSXML", see this post regarding cross platform support. Once the call has been completely the library usually bubbles the event back up to the method you state.
For more details and a 100x better description see this doc.
So now you know what AJAX is, what do I have to say about it...
I don't want to cover everything that is stated in both those documents you can read them if you like. I intend to just cover the highlights and give my thoughts on what I'm seeing.
So the first thing we see is the fact that Microsoft has put allot of thought into the OOP aspect of programming (thank god!). We see that we get some tools for allowing Namespaces, Inheritance and Interfaces. You can literally register namespaces with the Type system on the client setup a class hierarchy and even implement interfaces. The syntax looks a bit strange but I'm sure we can adapt.
What's cool is this next line:
As we expected, we can send and receive complex types via this toolkit. I wonder what serializer is used. The SOAP Serializer seems obvious for those calls to an actual Web Service endpoint, but what about non-Web Service endpoints? I hope we can just use typical/raw XML with out the SOAP bloat (envelope, body, etc). For SOAP Envelope's do we also get header support? Oh, I don't see any example of getting nor setting data with a DataSet. I bet you that this will be baked in as well. I personally limit my use of DS's but MSFT has pushed them onto us so much that most people do use them and you can expect support for them.
Caching data received from an ASMX's seems pretty obvious. Do it on the server as we normally have done in the past.
Exposing a DataSource for Atlas to consume is as easy as pie. Take a look at the examples, some really amazing stuff going on there. Setup your service to inherit from "DataServer", implement the required methods; add the atlas:DataSource control to your page, point it to your DataService (asmx); add some control (for example a atlas:ListView control) and point it to your DataSource then wire up the events like click and such. A simple three step process to wire it all up, now that is what I like to see.
ASP.NET Atlas Controls:
This is where things start to go downhill. It would appear that the Atlas team has invested in an extensive library for markup of our client sided forms. The sections of code marked under "<script type="text/xml-atlas">" and "<script type="text/xml-script">". I personally don't like this direction. What are they thinking!? Currently, we have an object model for markup and event handling for controls on the server and now they want to add a completely new model for the client?!
Why could we simply not take advantage of this "runat" attribute on our server sided controls and let the framework put it all together for us? runat="client"
I understand that this stuff is (probably) not going to be included directly in the framework, v2, and will be shipped as a separate install, but come on guys! Another completely separate Object Model? Is that really necessary? How many will actually use this? Is there plans to actually include it in v3 of the framework?
With the coming of XAML we will see yet another object model. That brings up my next point…
My style of Adaptive Rendering…
I have a great idea, which I stated many times already. Let's leverage this whole .NET Framework thing and create rendering engines. That is, this now called "adaptive rendering" we see in v2 for Web and Mobile controls, let's extend that right out. Have a single set of controls which us hard working developers need to learn and Microsoft, you build us rendering engines for each platform: Web, Web+AJAX, Mobile, Windows Forms, etc. If someone hits our URL with a XAML browser (essentially a Windows Forms client) render for that request. If they hit with Netscape 2, render old school Web, etc. I hit with IE7, render for it. Let's avoid tacking yet another object model into the mix.
Server Class Library:
First thing that stands out is the Microsoft.Web.Services.Converters.DataSetConverter. As I suspected it looks like they will be baking in some support for DataSets. Along with that it appears that we will be able to create our own Converters, just based on the Microsoft.Web.Services.JavsScriptConverter. Nice to know.
Here we get to see all of the control classes which are currently exposed to the client. Nice big list, unfortunately its an entire new set of controls we will have to learn. Boo!
What I would like to see as another final deliverable is a cross browser support matrix. I want to know exactly which feature is and is not supported on each and every (semi)popular browser on the market today, their versions and on alternative OS's. Scroll down on this page to get an idea of what I would expect. I think if MSFT really wants the industry to adapt this technology they will need to prove that it has a wide support base in the industry. Given this matrix it would allow us to really narrow down our browser/OS targets and enable us to make a more educated decision.