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.

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.

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.

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.

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?

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”).