Some observations on Script Callbacks, "AJAX", "ATLAS" "AHAB" and where it's all going.

I've taken a more than cursory interest in the whole Remote Scripting (.NET species) vs. AJAX and now ATLAS discussion, mostly because I started using Remote Scripting since Microsoft first released it, and because I continued to refine it after seeing Brent Ashley's excellent work with JSRS, which was one of the first "real" cross-browser solutions back in 2000 (that's the turn of the Century for you history buffs).

Now Bertrand Leroy, a Microsoft guy whose work I like, has authored some very interesting ASP.NET 2.0 script callback stuff that he points to on his blog, and he is obviously (at least, to me he is) involved quite heavily in the development of this new ATLAS infrastructure that they'll preview at PDC. Leroy's most recent post brings to the surface what I agree are the major differences between the "AJAX a - la .NET" approach as popularized by Michael Swartz with his AJAX.NET library, and Leroy's RefreshPanel, the ASP.NET 2.0 bullt-in Script Callbacks and interfaces and finally, to follow, the ATLAS offering that Microsoft is working out as I write:

Leroy states that their callbacks are an integral part of the page lifecycle and thus carry with them the weight of the state of the page. He goes on to explain that most "AJAX" users seem to expect to just query data out-of-band, not necessarily trigger server-side events in the stateful context of the page.

According to Leroy, "If you are a control developer, nothing outside of your control should be considered an asset simply because it's not responsible for it. Many Ajax control developers think like page developers and expose properties that will point the control to some service url that will feed them data. " (N.B.--this is what AJAX.NET does, preventing direct server-side access to the page from which the callback was initiated).

Leroy continues, "We avoid that kind of architecture because we want our page developers to be able to drag and drop the control to the page in the designer and have it working immediately. We don't want them to have to write a separate page, handler or web service for that. We want the control and the page to be self-contained components. To achieve that goal, we need the out-of-band calls to go back to the page itself and not to some external url.

We also want the callback event to be able to access all the richness and statefulness of the page and its control tree. In other words, we want a callback-enabled control to be able to interact fully with its context on the page (data sources are the main example). Finally, we want the callback model to be as close as possible to the existing postback model: we want simple events on simple controls."


He goes on to explain that the "AJAX" developer is composing existing controls, orchestrating their relationships with each other and the other layers of the application using event handlers, and that it is this last point that is relevant to Ajax: the orchestration with other layers of the application. Typically, the page will exchange data with other layers. This is very different from callbacks which are actually controls triggering events on themselves.

If you're just going to exchange data with another layer, you don't really want all the extra weight of page statefulness. What you want is the data and nothing else (The current "AJAX" view, for the most part).

Finally, Leroy finishes by saying that both approaches are complementary. They've understood this from the feedback and it is something they are going to address with the Atlas framework (among other things).

This is good, for two reason:

1) It shows that Microsoft is very interested in developer feedback both from the "AJAX" club and the "script callback server control infrastructure" club and intends to provide a framework that addresses both.

2) It shows that the Microsoft view is looking (I think) a bit farther over the horizon into the future than those who are looking to clone ASP.NET server objects (DataSet, for example) with Javascript as if it was a truly OOP programming environment (which it is not).


So, in my opinion, it will be worth the wait. In the meantime, if you are an ASP.NET developer (1.1 and even looking at 2.0) and want something that does most everything AJAX.NET does, without the obvious problem of separate "service urls" (e.g. phantom page extensions ) to make it work, and that does all this in only about 400 lines of code, look at Jason Diamond's library. I wrote a piece on it here (I changed the namespace to Remote Scripting cause this "AJAX" buzzword makes me want to puke, but otherwise it's all Jason's library).

On a side note, I think it's interesting, the kinds of comments you get when you take a position on something. Everybody's entitled to an opinion; everybody's entitled to respond and say they don't agree. I thought that was what blogging is all about, no? Usually, I'm pretty reserved, but when something (such as, for example, this "AJAX" misappropriation / buzzword phenomenon) rubs me the wrong way, well -- I'm gonna say exactly what I think about it! If people think its "over the top" or "pompous", or "snooty", so be it.

I have several issues with the use of the term "AJAX" (besides the obvious fact that it clouds the landscape with another unneccessary buzzword):

The examples that Jesse Garrett of Adaptive Path uses in his original piece "coining" the term AJAX simply do not qualify as "AJAX", according to his own definition. Google Suggest doesn't use XML or XSLT, it uses JavaScript arrays. And, none of their remote scripting stuff uses XHTML either. So when Garrett uses Google Suggest as the generally accepted example of their new acronymn, when it doesn't even match the criteria they've set out for it, it is not only a misstatement, it's a misrepresentation. Google's developers unassumingly refer to their remote scripting stuff as just plain "javascript". Obviously, they, who are arguably the best proponents of this technique on the planet, don't particularly see the need for a new buzzword either.

No question that Adaptive Path wants to sell services and seminars off this. To say to people "this is how we build web sites, which is kind of like how Google does it, but they actually use a different technique" is pretty complicated compared to saying "Google uses AJAX, and so do we." This is, at best, a real stretch of the facts.

Finally, the unfettered promulgation of new acronymns into the technical lingosphere when they do not particularly add value (e.g. they don't really represent any clearly defined "something new") serves to confuse the landscape and make it more difficult for developers. This is especially true for newer developers, who in many cases are now getting all hopped-up about "AJAX" and actually have NO IDEA that it is only a new name for a technology called Remote Scripting which was invented and released to the developer community by Microsoft last century (circa 1998), and that AJAX doesn't offer one single thing that makes it qualify as an actual "new" technology. All the "pieces" that Adaptive Path claims make up "AJAX" have all been used, in whole or in part, by many many developers, many times over the last seven years or so before some marketer coined the term "AJAX".

One commenter whose post I read even went so far as to intimate that Adaptive Path caused a real firestorm with AJAX and that I (Peter Bromberg) was just resentful because I didn't have a hand in its development! Actually, Adaptive Path capitalized on a confluence of factors; the main ones being that most browsers now have some sort of implementation of Microsoft's original XMLHTTPRequest object. Up until very recently, only Internet Explorer did.
So, there was a lot of pent-up demand for this sort of feature, and Adaptive Path capitalized on it. Even without XMLHTTP, Google Suggest degrades gracefully to the hidden IFRAME technology (JSRS) made popular by Brent Ashley in the year 2000.

You know what? I call it "AHAB" (ALotta Hype And Bullshit). You can call it whatever you want to, it's not going to bother me. The fact of the matter is, it's still just plain Remote Scripting.

N.B. Whoops! Somebody else did me one better!