How Safe Are Hidden AJAX Requests That Fake Performance?

ajaxdesignerror handlingjavascriptweb-development

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?

Best Answer

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