Take the 2-minute tour ×

As you may know, XMLHTTPRequest can be used synchronously or asynchronously, but synchronized requests have always been considered bad practice, and I've always agreed with that.

Not only is the ideology of modern JS development heavily based on an event model, but there were also some more prosaic reasons to avoid synchronized requests. For example, old Internet Explorer versions could just freeze suddenly.

Today I saw a synchronized request in Liferay source code and thought "What a shame, how dare they. Don't they know that it is wrong?". But then I asked myself what is actually wrong with this approach in modern times, and I wasn't able to give an accurate, logical answer.

For example, on the server side it is common practice to use synchronized HTTP requests. Of course all the data could be fetched asynchronously, and perhaps should be fetched that way, but we often need data that will be used to fetch another chunk of data, so in that case the request must be synchronized.

So, should this still be considered bad practice?

PS: I haven't used the term AJAX since the first A stands for asynchronous. :)

share|improve this question
Just because synchronous IO on the server is common doesn't mean its good. async IO is better, it's just not as "easy" to write. –  Raynos Oct 6 '11 at 11:28

1 Answer 1

up vote 5 down vote accepted

In short, yes.

Synchronous HTTP requests halt execution of subsequent code while they are en route. While browsers may no longer block the UI during this time, we're relying on the user's available bandwidth, network reliability, and the server's current load for the performance of our code. This is generally not good practice.

On the MDN "Using XMLHttpRequest" page, there is also a vague warning about memory use and event leakage when using synchronous XMLHttpRequest. There is no detail given, but given that the UI is not blocked, and JavaScript is, it would make sense that we might miss UI events we would have caught had we been using Async.

Note: You shouldn't use synchronous XMLHttpRequests because, due to the inherently asynchronous nature of networking, there are various ways memory and events can leak when using synchronous requests.

Edit: Server Side

While I agree that synchronous requests are common, I don't know that they're best practice. They may, however, be better practice on the server than on the client. It is better to put faith in your own server and its network connections than it is to put faith in those of your user. The server is (theoretically) a constant, the client is a variable. There are also no UI issues to deal with, and no possibility of uncaptured events.

share|improve this answer
Ryan, but, once again, when we are talking about serverside solutions, it's pretty common to do something like data = req_sync(some_params); req_async(build_params(data)) –  shabunc Oct 5 '11 at 13:28
besides, if it so useless, why should we even try to keep in in standard? I'm not arguing, actually, as I have wrote, I always said that sync it an evil, I'm just trying to be more objective. –  shabunc Oct 5 '11 at 13:30
Ah, I did neglect the server-side portion. Will edit. –  Ryan Kinal Oct 5 '11 at 13:34

Your Answer


