Tuesday, June 13th, 2006

Is “Asynchronous” Really Used in Ajax?

Category: Remoting, Usability

“A” may stand for Asynchronous, but PPK recently asked his readers if people are really exploiting the asynchronous nature of Ajax. Are there really situations where the user can do something while a request takes place? For instance, GMail makes an asynchronous call to grab some mail data – do you actually play around with other controls while the data downloads? Probably not. So he’s wondering…

(W)hether asynchronous communication is all that it’s cracked up to be from a practical point of view. If in practice it’s not useful to initiate a new request while waiting for the response to a previous request, Ajax’s main user interface advantage is kind of nullified.

The comments to that post indicate there are indeed practical uses of asynchrony … he’s subsequently summarized four kinds of asynchronous usage:

  • Sending data to the server (AKA fire-and-forget)
  • Refreshing data (AKA polling, Periodic Refresh)
  • This is the (as yet single) example of Ajax as I always supposed it would work: quietly but incessantly refreshing the page content based on repeated user actions
  • New “pages” (AKA Microlink)

Posted by Michael Mahemoff at 5:38 am

3.8 rating from 48 votes


Comments feed TrackBack URI

I love GMail’s attachment nature. Many times open a new mail, attach a file and start typing the email. GMail uploads the file asynchronously and saves me time that way. The same applies to the automatic saving of drafts.

Or take netvibes. While I flick through the entries in one feed it updates the others in the background.

There’s two reasons for Asynchronous in AJAX.

Comment by Chris Heilmann — June 13, 2006

A “Sending data to the server (AKA fire-and-forget)” example is:

Gmail’s Star on each conversation (in the Inbox view) and the Star on each email item within a conversation (in the Conversation view) are done asynchronously – it assumes the request will succeed and updates the view of the star (on -> off -> on) automatically. You are free to continue working whilst the call to update the server is completed.

Comment by Nic Williams — June 13, 2006

One scenario that is important (at least for me) and missing: aggregating data from multiple “sources”:
You have one page that is loading a graph, each element of the graph has it’s own information, that you are also loading. In this case ajax let you display the graph and the data as soon as they are loaded. Old school: the server is doing the aggregation which is not always possible (e.g. long queries) or efficient.

Comment by Guillaume — June 13, 2006

[…] Great question posed by Ajaxian. […]

Pingback by Busted Silos » Is “Asynchronous” Really Used in Ajax? — June 13, 2006

I agree with the spirit of this article. Most, but certainly not all, user interaction with an application is synchronous. You need look no further than your desktop applications to see this is true. Pick and choose where you use async carefully.

Comment by sup — June 13, 2006

I use the asynchronous nature of AJAX to break up form submissions that would be too large to submit (even for a POST). By breaking up the request and submitting simultaneously, it gets around the request length restriction and I think speeds up the entire submission process (but that may not be the case).

Comment by Ryan — June 13, 2006

Having a aysnchrous UI work environment is something completely different than executing an action asynchronously from the event dispatch thread. Just because you have the capability to asynchronously execute an action in the background doesn’t mean your UI support your user working the same way. It’s fundamentally two different things!

If you really think about it. There aren’t many desktop UIs that allow for the user to work in an asynchronously fashion with respect to user tasks. Desktop app developers understand this distinction. They also know that block the event thread is bad even if the user has to wait for your network trip to finish before going to the next step. Network trips can completely hang your app, and your user gets no feedback and what’s happening. If someone billed AJAX as supporting the user to execute user tasks asynchronously then they over sold what it’s capable of. UI design has more to do with this than AJAX does.

Comment by Charlie Hubbard — June 13, 2006

I really don’t think AJAX is Asynchronous Programming. It is more of convenient Multithreaded Programming. When the request is sent by XMLHttpRequest Object to server, it does not release the connection with HTTP server and it is waiting for response. Asynchronous programming will definately require changes in the HTTP server architecture. Although we say XMLHTTPRequest object makes callback, but where is the hashtable of clients to be called. Server should maintain this table. An Illusion is created to make javascript writer feel that it is asynchronous.

Comment by Deepak Keswani — July 23, 2006

Leave a comment

You must be logged in to post a comment.