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

  • 1
    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
    Commented Oct 6, 2011 at 11:28
  • 1
    Bad practice is to do something in a not so properly way. That does not mean that it will not be useful in another scenario. Best|Bad Practices are not law. They are not even any standar. It's just conventional. The more tools/possibilities you have the better. I encourage to you to ask Liferay Dev Team about their synchronizedrequest. It can be a bug, or may be there's a good reason beneah. What doesn't make sense to you, doesn't mean that have no sense for anybody else. Don't you forget that the only word that means law is requirements
    – Laiv
    Commented Apr 29, 2016 at 8:33

2 Answers 2


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.

  • 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
    Commented Oct 5, 2011 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
    Commented Oct 5, 2011 at 13:30
  • Ah, I did neglect the server-side portion. Will edit.
    – Ryan Kinal
    Commented Oct 5, 2011 at 13:34
  • 1
    @shabunc Generally, everything that gets into the standard has to stay there for backwards compatibility, so the fact that a feature is still in the standard is never (by itself) an argument that the feature is good.
    – Ixrec
    Commented May 19, 2016 at 8:27
  • UI must be blocked, invariably, by any ECMAScript compliant script host, if a script halts as it would during execution of a [synchronous] XMLHttpRequest request. This is because ECMAScript mandates strictly single "threaded" code execution (mind that I didn't mean that a Web page has to be allocated only one thread) in a design effort to take fine-grain synchronization issues out of both the script host and the scripts it'd execute. Since the UI may be interactive, for event listeners to be executed, the script must not be halted but have completed a "tick". Long story short. Commented Sep 8, 2021 at 14:06

Here is a good reason not to totally abandon sync calls just yet.

You have just downloaded a new tool from a vendor.

You get it working in your AngularJS application. (you spend weeks at this POC)

Then you are asked to use one option that has to communicate to your web server.

You create OWIN secure applications, so ALL calls must be Authorized!

The option to upload/download NEEDS to have an Authorization Token.

Authorization Tokens time out!!

So you must get a new one so that it is fresh BEFORE you start the option to upload/download.

BUT the option to upload/download where you get the Authorization Token is a event handler WITHOUT Promise/Q/$q capabilities.

Javascript is single threaded, so promises are not executed until the end of the event handler!

So you HAVE to do a Synchronous XmtHttpRequest!

I believe we should use Asynchronous Calls, but until Javascript is multi-threaded or event handlers return promises or Tool vendors use promises; we will need a Synchronous XmtHttpRequest call for secure web sites, just to refresh Authorization Tokens!



  • Are you saying authoriztion tokens time out after a certain number of event loop tickets, or a certain number of real-world seconds? This argument only makes sense to me if it's the former, and that seems very unusual.
    – Ixrec
    Commented May 18, 2016 at 21:33
  • Ixrec all authorization tokens should and do time out. My argument is pointed at the gap between the timeout of token and the need to have a fresh token. Vendors of some HTML/CSS tools only allow for synchronous calls inside their event handler. This makes refreshing the authorization token impossible without a synchronous call from within the event handler. This only applies when a communication to the web server is required from with in the event handler (for whatever reason). Remember I didn't write the event handler, the tool's vendor did
    – GregJF
    Commented May 19, 2016 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.