1 Posted by Jesse Skinner on 9 June 2006 | Permalink

Sometimes it's really asynchronous, I guess. For example, I've implemented a timer-based auto-save feature in a rich text editor that is certainly asynchronous.

If the user is waiting for something to load, that needn't be asynchronous. But when the user is finished and clicks 'save', the user could go do something else while their last action saves asynchronously.

2 Posted by Chris on 9 June 2006 | Permalink

Here's another use-case:

I'm categorizing lots of items. I click on one to select it. A div pops up with a list of checkboxes showing what categories I can tag it with. As I click, requests get dispatched to update the database.

Sure, you could incorporate a Save button, but if you need to tag lots of items, it's faster just to go click-click-click and let the app sort it out.

Off the top of my head, it also makes sense for GMail's virus scanner to work asynchronously. I should be able to read the sender's text while that happens.

3 Posted by Day Barr on 9 June 2006 | Permalink

> an application that counts on the users taking other actions while waiting for a server response

The most common example would be chat applications (the hello world of Ajax?). They allow the user to type a new message while other people's messages are received in the background.

4 Posted by Simon Willison on 9 June 2006 | Permalink

Digg is a great example. The whole idea of "digging" something is reliant on it being a low-overhead operation - thanks to the asynchronous nature of the site you can just click "Digg it" on stuff you like and move on without waiting for the server response.

5 Posted by Johan on 9 June 2006 | Permalink

I interviewed Cameron Adams on devlounge (http://www.devlounge.net/interviews/cameron-adams-aka-the-man-in-blue), he mentioned Meebo (http://www15.meebo.com/), a chat client app.

He said this about Meebo.

"At the time it was released, it was also the first instance I’d seen of a web application using a “Push” methodology rather than “Pull” — when the server has data it sends it to the client, rather than the client continually having to request data from the server."

6 Posted by Joost Diepenmaat on 9 June 2006 | Permalink

As soon as you use the the onreadystatechange callback, which is the default, you are by definition using asynchronous code.

This is a recommended practice, since there are many ways a synchronous request can block for ages, taking your whole javascripted page down with it.

Aside: this is exactly the reason you don't have a sleep() function in JS, but only setTimout callbacks. Callbacks allow the browser to control the order in which GUI/HTTP/Timer/Whatever requests are handled.

Day Barr's example is very good: for a chatbox you'll want to be able to request updates (i.e. other user's message) while the user should still be allowed to type / send new lines etc. You don't want to let a slow server destroy the user experience.

So, as an example of asynchronous AJAX, here's my chatbox code:
http://zeekat.nl/downloads/chatbox/index.html

7 Posted by Liam Hesse on 9 June 2006 | Permalink

I'd say Gmail is *occasionally* asynchronous.

While I compose a reply or a new message, Gmail saves my work - *in the background*. Unobtrusive, asynchronous, no prompting. It just does it - and I carry on writing the message.

So yeah, for me it fits in the "asynchronous" category - but only in some cases. Others, like the one Peter brought up - refreshing the mailbox, moving from Inbox to Drafts or suchlike - are not asynchronous.

For me, the question is "does it work well enough?" And I find the answer is always a resounding Yes.

8 Posted by Kapitancho on 9 June 2006 | Permalink

Usually there is a certain workflow and its steps should be followed exactly so the A in AJAX seems to be rarely used in most of the AJAX applications.
For example, a dialog data is saved and after that some parts of the page should be reloaded. Obviously, the parts cannot be reloaded until the dialog data is saved.

9 Posted by Joost Diepenmaat on 9 June 2006 | Permalink

@Kapitancho: but you can still do that asynchonously - it's what the callback is for. Asynchronous code doesn't mean certain actions can't wait on each other - it just means you can do other stuff while waiting for the first action to finish.

10 Posted by Jordan West on 9 June 2006 | Permalink

I am currently working on a project that works somewhat like the google home page http://google.com/ig. I use asynchonous code here, because as the user drags and drops an object, i save the information to the database, but the user can still interact with the page, and drag and drop other items. If the user would have to wait for the database to save, it would be very unattractive, especially if they have a slow connection or the server is particularly slow that day. I can see where Async, really isn't async, but there are many practical implementations of it also.

11 Posted by Ryan Platte on 9 June 2006 | Permalink

The 37signals guys go for simplicity whenever they can, but their Backpack to-do lists accept input of a new item while the previous entry is being sent to the server. It would be way too slow without that being done asynchronously.

12 Posted by Seb Frost on 9 June 2006 | Permalink

I'd say the benefit in gmail comes not from what you're talking about but other, lesser actions - like when it automatically saves a draft of the message you're writing.

There's little point (in my mind) of using ajax to load what is the main bulk of the page - you may as well do a traditional hyperlink/HTTP request.

A site I've used ajax on extensively is a scheduler system for a large UK-based organisation. They have engineers who log in to a view which lets them assign contracts, day types etc to each day. It's a huge table (especially since they like to view 2-3 months at a time) and even with all of my best space-saving techniques the page weighs in at 60KB of HTML. So when they make a change I'll use ajax to update the DB instead of making them click "save" and having to reload the whole page.

It works great, and feedback on the system has been very positive. Regrettably I can't provide a link as obviously it's a secure intranet app.

13 Posted by Alex Lein on 9 June 2006 | Permalink

My ajax app needs to be asyncronous. It's a fleet monitoring program that needs to be able to update (in real time) a vehicle's position even if the user isn't monitoring that vehicle at that time.

I also find it nice to use the async requests as throw-away requests where a response from the server is unnecessary. Sending a request for a GPS position doesn't require the server to say "ya, ok, sent" since that is the only possible response (other than "you're logged out!").
aka: click a button, request is sent async and you dont need to wait for that 1/2 second for the client to acknowledge the response.

14 Posted by Dan Knapp on 9 June 2006 | Permalink

You are overlooking something obvious - google maps. It preloads images outside the area being viewed, even as the user drags them around. And if the user does scroll past what's been loaded, he can continue to drag while the missing cell gets filled in.

15 Posted by Max Antoni on 9 June 2006 | Permalink

All applications I know (also google maps) work, or would work in the same way the do, even if the requests to the server are queued. Although the user is able to continue working with the page, there is now case I know, where the user really needs asynchronous operations on a request basis.

Imagine two operations, A and B: A is fired first and while waiting for the response, B gets fired. I don't know an example, where it is important that operation B can complete before A.

Therefore I don't think real asynchronous request are needed in most web-apps, except I'm overlooking something obvious as well.

16 Posted by Kevin Pirkl on 9 June 2006 | Permalink

Hmm, the underlying foundation protocol (for MS Windows Systems at least) for scripted AJAXian style connections to server is perhaps limited on by WinInet's capabilities per http://support.microsoft.com/kb/183110 thus I think you have very limited asynchronous communications ability, not to mention that I am not entirely sure about JavaScript's running thread/process model... Just some thoughts..

17 Posted by Guillaume Bokiau on 9 June 2006 | Permalink

Another example of real asynchronous communication in gmail is when attaching a file to a mail. You can continue writing, attach another file or even already send your mail while it is being uploaded. And that's a major time-saver.

18 Posted by TwoD on 10 June 2006 | Permalink

Google Suggest also requires async calls, even if it's a rarely used feature. Imagine having to wait for the response after typing each character in the search box... :(

Google seems to be one of the pioneers using async calls in big applications, even if they aren't needed, they make the user think it takes less time because he/she doesn't see the whole reloading process. If a "Loading" notification appears and then disappears, and the user knows he/she *could* still look around/scroll the page/whatever during this process, the application feels faster and lighter. It sure beats having nothing to do but wait for the page reload.
It's one of those features which aren't needed for the function of the application, but make all the difference when it comes to user experience (or rather what the user thinks he/she is experiencing)

Also noteable is that Gmail uses the async calls to avoid downloading all the heavy HTML after the initial logon. After that, the responses are just ready-to-run JS code which saves a lot of bandwith in the long run.
Use a HTTP sniffer (like fiddler) to see the heartbeat of Gmail querying for new mails about once a minute. It also keeps the session alive so you'll never timeout if you keep it open.

19 Posted by Curtis on 10 June 2006 | Permalink

You guys used very good examples. One thing I noticed about the whole Gmail experience overall, is that even on dialup, everything was very responsive, since the whole page need not be refreshed after each request. Well, thankfully, I'm not on dialup anymore!

To more specifically address the question, I think the examples used about Google Maps and Gmail's auto save were very good.

20 Posted by crusty on 10 June 2006 | Permalink

do asynchronous protocols really prevent deadlock? or do they just bubble up deadlock states to the script level...allowing the rest of the app to proceed in a potentially crippled state? not many ajax-style apps induce mandatory state changes, but i can imagine some that might - passphrase verification etc. these states can be managed with callbacks, but it becomes a spaghetti issue, likely better handled by a server-side script...thoughts?

21 Posted by Vladimir Stepanov on 10 June 2006 | Permalink

Flickr, for one, does make use of this asyncronous stuff when it comes to editing titles and descriptions of photos. There's a bunch of previews, some 20 per page, and you can edit the title of the first, push "Save" and go to the second, while the first one is still waiting for a confirmation from server ("saving is in process" or something like that appears in place of the title). So you may change titles/descriptions of all photos, and you'll have to wait only once in the very end.

As to Gmail, it's not really 100% Ajax-friendly. I happened to observe the following. I have pushed the "archive" button and the message went to the archive, but some time later I notice that the connection was lost at or just after the moment I pressed the button. I reconnected and here it was, my archived message, marked as unread...

22 Posted by ptt on 11 June 2006 | Permalink

I just have a minor comment: I don't think "asyncronous" is the only advantage of using AJAX techniques. My application framework uses a hierarchical, component model for each page. After each "AJAX" user action, the framework calculates what components on the page have changed and returns only that content. This provides a much more responsive and interactive UI: especially in displays with highly nested tree controls, pages with multiple forms, etc.

23 Posted by Nick Fitzsimons on 12 June 2006 | Permalink

Liam Hesse makes a good point in that the asynchronous nature of the request stops the browser being blocked: I can switch to another tab, say, even as some server-communication based processing is going on.

I created a WYSIWYG CMS for a company last year which allowed them to reorder content by dragging and dropping pages in the sitemap. In my testing I was able to move stuff around at great speed as the database was updated asynchronously; however, during user testing, I noticed that they tended to drag something, wait for the change in highlighting that showed that the dropping process was complete, then drag the next thing. (They didn't have a clue how it was all happening, but just had the idea that it was safest to wait until the last bit they'd manipulated had gone back to looking "normal" before trying to do anything else.)

24 Posted by Kapitancho on 12 June 2006 | Permalink

@Joost Diepenmaat

Yes, this is true. But there is a need to forbid the user to do action in the meanwhile and this can be done by some 'loading' gifs or semitransparent layers on the top of the page.

So in fact it seems that A in AJAX is used technically but visually the user usually cannot feel the A in action:)

25 Posted by Adnan Siddiqi on 13 June 2006 | Permalink

What is needed to be explored is cross-domain session.I am struggling to create/retrieve sesion variable values via AJAX because everytime AJAX call is considered as a seprate session.Any idea to sort it out?

26 Posted by Mark Pruett on 13 June 2006 | Permalink

One asynchronous use case I haven't seen touched on (except peripherally with mention of Google Maps) is predictive fetching. I have applications that display historical data on a "day at a time" basis. I have a browser side data cache (hash) and when the user selects day n, I'll sent out two additional requests -- for days n-1 and n+1 (unless they're already in the cache).

The application has "next" and "previous" buttons. If the user presses "next" to see the next day's data -- it's already waiting in the cache. It takes a little extra server processing (they may never look at the data I've silently cached for them), but their user experience is improved.

27 Posted by Pablo Palacios on 13 June 2006 | Permalink

Actually I made a few nice AJAX pages in a small application that needs to execute big batch processes in background, the can run for a few hours, so I use an async bar to let the user know how the batch is running while they work on something else.
Also my system blocks the use of pages related to those batch executions and release them when they end

28 Posted by Charlie Hubbard on 13 June 2006 | Permalink

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 supports 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 asynchronous fashion with respect to other user tasks. But, UI programmers have to execute code asynchronous when they write desktop apps. Outlook doesn't allow you to do this, but it certainly doesn't freeze the UI thread while it makes a trip over the network. How many of them let you execute an action without making you wait for the results before executing another action or step in that process? This is really more about how humans (ie users) think about subdividing work which is NOT asynchronous by nature.

29 Posted by Mark Pruett on 14 June 2006 | Permalink

Charlie Hubbard wrote:
"Just because you have the capability to asynchronously execute an action in the background doesn't mean your UI supports your user working the same way. It's fundamentally two different things!"

You're quite right, of course, but the title of the piece does ask the more general question: "is async communication really being used?"

As to the specific question about UI interaction, we wrote an object that disables a set of UI widgets when an async call they depend on is pending. The user is given visual feedback (a little animated "twirly") when the widgets are disabled. The rest of the UI is still useable. I thought the visual cues would be irritating, but in fact they're not bad.

There is the education issue: the user needs to learn that only *part* of the UI is disabled. I think the natural tendency for the user is to wait whenever they see the twirlies.

30 Posted by Alan Walker on 14 June 2006 | Permalink

Sending data to a server in the background can be useful for Web-based games.

In my Chihuahua word puzzle (http://chi.lexigame.com) where people make words from a set of letters, each word made is validated on the client and sent in the background to the server to update the scoreboard. But the player's view of the scoreboard is updated immediately by the Javascript, so the player just keeps on playing. When the reply comes back from the server, there may be changes to other players' scores.

Also, the JavaScript can keep track of which words have been acknowledged by the server, so if a request hasn't made it for some reason, the word will be re-sent with the next word made. So, the application can handle the occasional glitch on the server without the user being any the wiser. (I suppose if you wanted to make things truly robust, you could store any unsaved data in a cookie, for re-submission the next time the user visits your page.)

31 Posted by Martin on 14 June 2006 | Permalink

For most applications I agree that asynchronous calls not make sense. You don't go fiddle with other contols while you're waiting for the next 10 emails to be loaded.

However, we've implemented AJAX technology for online chat/adventure games since 2001, which you can see on http://www.quek.nl or http://www.goodoldadventures.com. They aren't that firefox friendly I'm sorry to say, but for this article's sake I thought I'd show a good practice of asynchronous calls.

What we do is ping the server from time to time to see if there is new info from people in our current (virtual) room, and while we're at it we just post our recent changes (movement, chat, etc). If we'd made those calls synchronous, you'd have to wait dragging or walking around until the reponse is back. The asynchronous aspect of this is what gives users a feel of actually being in a live environment.

Cheers.

32 Posted by Ben on 19 June 2006 | Permalink

The maps example is particularly poignant to this discussion when you have thousands or millions of markers to map. My application is like this. When a new center is acquired after a map move, the app starts plotting potentially hundreds of new markers. However, the user can move the map again without waiting for the markers to finish plotting. The app detects this, bails on the outdated request when it eventually finishes and starts a new request for markers. This way the user can continue interacting without waiting for a list of markers. It fits your use pattern perfectly.

33 Posted by Saqib Shakil on 6 December 2006 | Permalink

I would say the most primitive ajax example fits best the auto complete. The user just keeps on typing and the server suggest further entries if it would be synchronous no one would use it