Ajax at the moment is gaining a lot of popularity for its ability to make out-of-band calls to remote scripts by way of XMLHTTP that function as server-side handlers wired up to client-side JavaScript events.  This programming model, for the moment with the growing community of samples available on the Web, is used to process relatively small amounts of data, such as simple database queries and other things with minimal payloads to send across the wire. The data is bound to server-side controls and/or DOM objects for display on a page without the waiting of traditional web applications.  This is the essence of Asynchronous JavaScript and XML.

But when I think of the deeper meaning of programming asynchronously, I also think of long-running operations, as in the case of performing async web service calls - those that might need to wait for a certain occurence before returning to the calling application (like the canonical stock broker application).  I also lean towards associating scheduled execution when I think of asynchronous programming.  Microsoft's Atlas initiative includes timers as part of its built-in Client Script Framework, which I'm looking forward to playing with for this reason entirely.  We've wanted desktop-style timers in web apps for years, which will make timed firing of scripts more accurate, reliable and programmable than doing a page refresh or redirect by way of a <META> tag.

So will Ajax allow for larger amounts of data to be processed?  I hope so, with the vendor implementations of Ajax.  Given certain conditions that aren't so bound to client-side events like OnKeyUp or OnFocus and that make an app subject to greatly reduced performance because of repeated calls against a data store.  In this scenario, returning light amounts of data or data from a caching tier is critical.  And further, will we be able to actually delay the processing of a remotely-called script or schedule it somehow?  Surely.