What is a hidden AJAX request?

I've noticed an increase in the usage of hidden AJAX requests designed to make a user's action appear to happen immediately. I'll refer to this type of AJAX request as non-blocking. It's an AJAX request made without the user being aware it's happening, it's performed in the background and it's operation is silent (there is no verbose to indicate a successful completion of the AJAX call). The goal is to make the operation appear that it has happen immediately when it really has not finished.

Here are examples of non-blocking AJAX request;

  • User clicks delete on a collection of emails. The items disappear immediately from their inbox, and they can continue with other operations. Meanwhile, an AJAX request is processing the deletion of the items in the background.
  • User fills out a form for new records. Clicks save. The new item appears in the list immediately. The user can continue to add new records.

To clarify, here are examples of blocking AJAX request;

  • User clicks delete on a collection of emails. An hourglass cursor appears. The AJAX request is made, and when it responds the hourglass cursor is turned off. The user has to wait a second for the operation to complete.
  • User fills out a form for new records. Clicks save. The form turns grey with an AJAX loader animating. A message is shown "Your data was saved", and the new record appears in the list.

The difference between the two above scenarios is that a non-blocking AJAX setup does not provide feedback of an operating performing, and a blocking AJAX setup does.

The Risk Of Hidden AJAX Requests

The biggest risk of this style of AJAX request is that the web application could be in a completely different state when the AJAX request fails.

For example, a non-blocking example;

  • User selects a bunch of emails. Clicks the delete button. The operation appears to happen immediately (the items just disappear from the list). The user then clicks the compose button and starts typing a new email. It's at this time that the JavaScript code discovers the AJAX request failed. The script could show an error message, but it really is pointless at this time.

Alternately, a blocking example;

  • User selects a bunch of emails. Clicks the delete button. Sees an hour glass, but the operation fails. They get an error message saying "error. blah blah blah". They are returned back to the list of emails, and they still have the emails they wanted to delete selected. They could attempt to delete them again.

There are also other technical risks for performing non-blocking AJAX requests. The user could close the browser, could navigate to another website and they could navigate to another location in the current web that makes the context of any error response meaningless.

So Why Is It Becoming So Popular?

Facebook, Google, Microsoft, etc.. etc.. all these large domains are increasingly using non-blocking AJAX requests to make operations appear that they are performed instantly. I've also seen an increase in form editors that have no save or submit button. As soon as you leave a field or press enter. The value is saved. There is no your profile has been updated message or saving step.

AJAX requests are not a certainty, and shouldn't be treated as successful until they have completed, but so many major web applications are operating just like that.

Are these websites that use non-blocking AJAX calls to simulate responsive applications taking an unnecessary risk at the cost of appearing fast?

Is this a design pattern that we should all be following in order to remain competitive?

  • 20
    This is justified by the fact that successful operation is much more likely, therefore being slow just to avoid the rare case of over-optimistic feedback is a bad trade-off. Transposed to personal relationships, would you rather interact with a calm, sunny person or one who categorically assumes that everything that can go wrong will go wrong and acts accordingly? Commented Jan 31, 2013 at 15:54
  • 1
    For me, what I'm struggling with, is that a desktop application has both the operation and error happen immediately. Where as, with web applications the operation happens immediately, but the error is lagged. Yet, sites operate with the design of a desktop application.
    – Reactgular
    Commented Jan 31, 2013 at 15:57
  • 7
    Have you also considered what happens when your desktop application writes to disk, it actually goes into an OS buffer, and the disk fails before it could be written to the platter? Or, for that matter, the disk fails after the bytes are written to the platter. In both cases, the user thinks that something has happened when it really hasn't.
    – kdgregory
    Commented Jan 31, 2013 at 16:02
  • 2
    @KilianFoth I'd prefer the one who assumes everything can go wrong, if the "sunny" person is going to punch you and steal your wallet at the first sign of trouble. So it depends on the scale of the page's reaction on failure.
    – Izkata
    Commented Feb 1, 2013 at 3:55
  • 1
    @ButtleButkus I think those saving messages are new. They weren't there when I asked the question. I've notice google adding more feedback lately that's it's doing stuff in the background.
    – Reactgular
    Commented Nov 5, 2014 at 13:11

6 Answers 6


It's not so much "fake" performance as real responsiveness. There are a number of reasons why it's popular:

  • Internet connections are fairly reliable nowadays. The risk of an AJAX request failing is very low.
  • The operations being performed are not really safety critical. If your emails don't get deleted on the server, the worst that happens is you have to delete them again the next time you come to the page.
  • You can design your page to undo the action if the request fails, but you don't really have to be that subtle because it means your connection to the server is broken. It's easier to say "Connection lost. Unable to save recent changes. Try again later."
  • You can design your page to only allow one pending AJAX request, so your state won't get too out of sync from the server.
  • The browser warns you if you try to close or navigate away from a page while an AJAX request is pending.

AJAX pending warning

  • 8
    That last point, do all browser do that by default?
    – Svish
    Commented Feb 1, 2013 at 11:43
  • I don't know. I've only tested it on IE9 and the latest chrome. Commented Feb 1, 2013 at 22:39
  • 3
    You obviously aren't acquainted with Australian Internet, not to mention poor, developing, and isolated places, even mobile on a moving vehicle... Commented Feb 3, 2013 at 14:30
  • 2
    @hippietrail Well, you can't make everybody happy all of the time.
    – KOVIKO
    Commented Feb 7, 2013 at 22:50
  • 1
    When the user sends a request, he doesn't always ask for a new page. I think that well-designed AJAX applications can make them more enjoyable, letting the user know what's going on more efficiently than with a reload.
    – Frederik.L
    Commented Aug 14, 2014 at 1:35

Assuming something will work and displaying an error in case it fails on the remote side is much more user-friendly than blocking the user from doing anything else until there's a response from the server.

An email client is actually a great example for this: When I have a list with 5 emails and the top one is selected I expect that when hitting DEL three times the first three emails are deleted. With "nonblocking AJAX" this works fine - everytime I hit the key the selected email is removed immediately. If something goes wrong an error is shown and either the not-properly-deleted emails are shown again OR the page is reloaded to get rid of the inconsistent local state.

So in the most common case - that is success - it improves the usability. In the rare case - failure - the usability is degraded (deleted element shows up again or the application is "restarted") but when creating an application you usually want to have the best usability for common cases, not in case of errors.

  • 1
    +1 this is spot on the heart of the matter. There is so much safety by default people implement these days that in the worst case scenarios you still aren't risking true user mistakes: imagine the email client fails to delete, now local state is bad, and they try delete email 4 which is misaligned with the server, the vast majority of back-end devs will have a safety catch there to ensure you only delete what the user absolutely wants to and so this misalignment will not cause erroneous deletions (it may fail in error but it will not delete). Commented Jan 31, 2013 at 18:09
  • @JimmyHoffa you would use a unique email id in the delete request. It would be really bad to send delete requests based on the arbitrary display order of the emails in your inbox. Commented Nov 5, 2014 at 6:27

The users don't care about what your software is doing behind the scenes: they want their actions to have visible impact, and to be able to work at their pace.

If an action was successful on client side - like deleting emails - it's your job to make it successful on server side as well. Why did the deletion fail? If it's due to some kind of limitation (for exemple, you can't remove an email that has been archived), the user should be made aware of that before his action failed.

If the error is caused by something more severe (let's say a database crash), you should have a way to save the operation and re-try it when the system is up again.

A good exemple of managing this is the way Facebook handles the chat. There is no way to stop a user from disconnecting suddenly, which means they won't be able to read the messages you sent before they left. Instead of displaying an error, the system saves all those messages and makes them available to the user when he comes back. No data is lost.

  • 2
    +1. Excellent example chat. Most users expect their message to be immediately made available to everyone, and since such messages rarely fail, users are given the illusion that that is the case.
    – Neil
    Commented Jan 31, 2013 at 16:24
  • 1
    @Niphra, "Why did the deletion fail?" The network can fail for many reasons, none of which to do with your application. There's nothing you can do to stop that.
    – Pacerier
    Commented Feb 16, 2015 at 20:57

You can compromise between the two options. For example, if the user deletes an email, you could mark it red or grey it out until you get a confirmation back from the server, and only then remove it from the list. The user can still do other things while one action is pending, so it's not blocking, but it still leaves a little reminder for the user that their actions haven't been committed yet.

Amazon AWS takes this approach: when you stop/start an instance, the checkbox that allows you to select it turns into a spinner (so you can't do anything to it for a few seconds), but this doesn't block you from interacting with other instances.

  • Your suggestion is similar to how gmail shows "Saving..." text while the XHR is going, and "Saved" after it's done. If it always said "Saved," who would believe it? Commented Nov 5, 2014 at 6:29

I think, this comes together with more and more websites that try to behave like Applications and do more processing in the browser (like validating form data) than the more traditional sites. I don't see too much of a problem in that as long as your code is reliable and you can expect it to succeed under normal conditions.

You say "It's at this time that the JavaScript code discovers the AJAX request failed. The script could show an error message, but it really is pointless at this time."

Why should it be pointless? You can go back in the list of EMails and do the delete again. Why wait instead? There is actually not much of a "risk" and they do not "appear" to be fast, they actually work faster. So if the activity is not "critical" why be slow?

  • 1
    Maybe pointless wasn't the right word, but what I mean is that the error message lacks relative context, because the user is now doing something completely different. I'm trying to say, is that to a ignorant web user, they thought the emails did delete successfully. So why now, later, they get an error message for something they "saw" were removed. For us programmers, we understand, but for grandpa using gmail they wouldn't understand.
    – Reactgular
    Commented Jan 31, 2013 at 15:52
  • Most people would rather use an application where things happen immediately, the system is responsive and there's a 1 in 10,000 chance the UI might update in an odd way on an error than an application that freezes for one second every time they change a value.
    – user53141
    Commented Jan 31, 2013 at 20:58

My 2c is: there's situations when it's better to have, as you put it, "non-blocking" Ajax operations and others where it's a bad design choice. Example: voting a YouTube video. You don't really want any part of the page to be blocked while you click on the little starts there. It's better to silently fail. Even a confirmation message would be over-kill. However your example with email deletion I'd qualify as mandatory for blocking-type Ajax request.

Mongo DB does something like that (and this could be considered as a Desktop application example). They have various "Write Concerns" for their operations, and you can configure it to different values for each operation, ranging from "return right away and don't wait for anything" to "block until you've confirmation of successful network transfer and then return" to "wait till the content is properly scheduled for disk write on the remote machine before your return". Obviously, if you make Desktop thick client (in like C++) using the Mongo driver, you'd set the lightest write concern for db operations of minimal "criticalness" (such as checking for new email), and others on more strict write concerns.

While I see the usefulness of non-blocking Ajax, I do agree with you that it's happening too much. At a point there was at least one famous "social networking" site which would do this for photo uploading. You'd chose your photo to upload and then bam, right away it would tell you that it's done, and then sure enough the next day when you wanted to add some more photos (or use on that you thought you already added), it was never to be found. Later on they gave up on this, and actually took the time to wait for response (and you would indeed sometimes get messages like "failed to upload photo, try later").

  • +1 for seeing things my way :). The photo upload is a great example of it failing.
    – Reactgular
    Commented Jan 31, 2013 at 17:04
  • 1
    Why would a blocking upload be preferable? In Picasa (web interface), you can drag photos in, and while they upload in the background, you can drag more in, or tag photos that have finished, etc. A blocking upload operation would make that a horrible UX
    – BLSully
    Commented Jan 31, 2013 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.