As of jQuery 1.8, the use of async:false
in jQuery.ajax() is deprecated.
But how many webpages have you seen with a \"loading screen\" while there is an ongoing AJAX communication in the background? I have probably seen thousands of them.
My case is that I am writing a mobile app that needs to load a language file. And at the beginning I load the language file and I retrieve the text of the buttons and other GUI elements from the language file.
This is really bad for me. Because if the language file is missing, the GUI shouldn\'t appear. So how do I solve it? Put all my code in the success
callback? That doesn´t seem like a good coding practice to me. Can I solve it another way?
The solution is to manually add an overlay to prevent the user to interact with the interface, and then remove it once the AJAX query is done.
$(function() {
show_overlay();
$.ajax({
// Query to server
}).done(function() {
// Verify good data
// Do stuff
remove_overlay();
});
});
I read the official discussion in the ticket about the deprecation of this parameter and here is what I understood:
The problem is that implementing Promises (1) for sync AJAX gives them overhead.
There are tons of real world use cases of sync AJAX, e.g. preserving state before page unload. Therefore, this functionality will stay, but the way you use it may change.
The nearest solution (landing in 1.8?) is to support only callbacks (but not the Promises) when async
is false
.
To conclude: Keep using async: false
if you have to, but beware of its drawbacks (blocking of VM). Don\'t worry, you will be provided an alternative if this feature ever gets removed form $.ajax()
.
I would bet that many of those 1000\'s of pages don\'t actually block the UI while waiting for the AJAX call. Instead, they probably obscure the UI with the waiting screen at the time the call is made and then remove that on a response handler.
There are many ways to obscure the UI (you could even just use a jQuery UI Dialog that\'s set to Modal and has no escape or close buttons), so I\'ll leave that decision up to you. But the layout of the code would be something like this:
var someFunction = function () {
// any pre-conditions to the logic
// obscure the UI here
$.ajax({
url: \'ajax/test.html\',
success: function(data) {
// handle the response
// show the UI again
},
error: function(data) {
// handle the response
// show the UI again
}
});
}
I\'m sure there are multiple ways to achieve that order of events, but that\'s the general idea. Blocking the UI was never really the intent, and I imagine it was an even more difficult decision for jQuery to include that feature than it was to remove it. It\'s meant to be asynchronous.
Why would you use ajax to get this file? Just include it using a script
tag.
In any case, you don\'t put all your code in the onSuccess - instead you call a single function from there that starts your code running.