Looking back at all the feedback I got from my ongoing Fun with callbacks series, I understood a few things about what most people expect from an Ajax-like framework.
Our callback feature's implementation seems to be surprising for most of our users. It's actually quite different from the very lean and simple approach most Ajax samples are adopting. Our callbacks are an integral part of the page lifecycle and thus carry with them the weight of the state of the page. Most users seem to expect to just query data out-of-band, not necessarily trigger server-side events in the stateful context of the page. Why is that?
I think the main reason for this difference in the expectations and what we delivered is that we tend to think as control developers, whereas most of our users think as application or page developers.
If you are a control developer, nothing outside of your control should be considered a reliable 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. 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.
What we have is controls that look like ordinary controls (visually and in their object model) but can have better responsiveness using callbacks, so that developers using our technology can start using them and get the benefits of Ajax without having to know anything about client-side scripting or XmlHttp. And we're also exposing an API so that control developers can create new controls like the ones we're shipping with ASP.NET 2.0 (TreeView, GridView, DetailsView).
Now what about the page or application developer? This developer is composing existing controls, orchestrating their relationsships with each other and the other layers of the application using event handlers.
It's 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. Remember, this is very different from callbacks which are actually controls triggering events on themselves.
If you're 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. This layer may be exposed by some kind of web service or REST handler, but is not necessarily something you want exposed on the page surface. Ajax.NET and other existing Ajax frameworks deliver quite well on this point even though they are unable to do what we do with callbacks. So they answer a need that we don't answer well enough with callbacks, and vice versa.
What I'm saying is that both approaches are complementary. That's one thing we've understood from the feedback and something we're going to address with the Atlas framework (among other things).