Brock Allen wrote an interesting post
on his blog comparing Ajax and the callback feature of ASP.NET
. Most of the concerns he has about ASP.NET
callbacks are addressed in my Fun with callbacks series
and/or in the forthcoming Atlas project
Wow, what a great game! I just finished Jade Empire in "evil mode". I'm very likely to do it again in "boy scout" mode. The immersion and richness of the universe are just amazing. The only thing I disliked is the tendancy Bioware has to explain to us that the evil path is somewhat as honorable as the virtuous one. I enjoy playing an evil character (I know the subtle difference between game and reality as almost every other gamer on the planet), but don't try to tell me that he's not evil. Some of the things they make you do in this mode are actually quite disturbing. I'm still waiting for the (good) game that will let you play a Dr. Evil-like character: evil, but in a funny way. Yes, Dungeon Keeper did that in a way, but that was a long time ago.
By the way, looking back in time, the quality of a game does not seem to be dependant on its technical sophistication. My favorite games stood the test of time quite well and are still enjoyable today. They are:
What are your favorite games of all times?
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).