The problem with synchronous requests is that the application becomes paralyzed and dependent on something external to work.
In case the server, or the internet connection have problems and the answer does not reach the application is blocked, nothing happens. Not even a possible setTimeout
to reset to ajax... nothing. This is very bad and so this possibility is being removed from the Javascript world.
Yet there were those who mentioned in 2010 it is good to use this technique as a last resort for the onbeforeunload
, that is when the user closes the browser and the application needs to communicate with the server. But even here is a bad idea. In fact via jQuery is no longer possible in the new versions, this is deprecated. The xhr specifications and of w3c go in that direction too.
If after the user executes an action, you don’t want them to leave your page at all until the action is completed, it’s a good time to use AJAX synchronously.
– mau humor
My view is that this feature aimed to make code "easier" to write, since many programmers have difficulty dealing with callbacks and asynchronous execution, in addition to which it avoids the "additional work" of blocking repeated requests if the user clicks several times on a button, for example, and also avoids the need to put some kind of Loader for the user. Anyway, "nut" solution for lazy (or unsuspecting) programmer that takes years to remove because there are many people with these characteristics out there. At least this is my opinion. :)
– utluiz
See also What is the asynchrony?
– Bruno Costa
These links can be useful: Ajax is not a programming language. So what is? and What is the real advantage of using a Callback and what is thread/multithread?
– Guilherme Nascimento