This is one point where I agree strongly with the name AJAX – remember what that first letter stands for…

To grasp why, it’s worth seeing some examples and discussing which I’ve attmpted before here.

In essence, when you make a synchronous call with XMLHttpRequest, everything else stops and waits for the request to complete. And that means everything – even any intervals you’ve set. You can’t even abort() the request via the readyStateChange property (don’t believe me? try and watch a [browser dependent] crash…).

In other words submitting a synchronous request puts you at the mercy of the network and the server you’re making the request to. While developing on localhost, you’ll probably be unaware of this and living under the illusion that synchronous requests are just fine. But on a live site, if the server happens to get Slashdotted, while you’re busy SJAXing, expect a very long wait and a dead browser – to an end user, particular when using IE, it looks like it’s crashed (if I remember right IE does eventually recover but only after about 5 minutes).

To really get a feel for this you need to see it in action, which I’ll do with the help of a simple Python HTTP server that only accepts on request at a time, then goes into a sleep for 10 seconds before serving the next request. Any other incoming requests have to wait until the server is free to continue working. This sort-of-simulates a web server that’s got too much work to do.

Note if you’re using Windows and don’t have Python installed, do so – it’s completely painless. Make sure you add the python executable to your PATH (i.e. Start > Control Panel > (Administration) > System > Advanced > Environment Variables and add C:\Python24\ at the end of the PATH variable).

The code for the server is simply;

[code lang=”python”]
#!/usr/bin/python
# minimal web server. serves files relative to the
# current directory.
#
# See: http://effbot.org/librarybook/simplehttpserver.htm
# http://docs.python.org/lib/module-SimpleHTTPServer.html
# http://docs.python.org/lib/module-SocketServer.html
#
# IMPORTANT QUOTE:
# “[the basic SocketServer implementations] process requests
# synchronously; each request must be completed before the
# next request can be started.”

import SimpleHTTPServer
import SocketServer
import time;

PORT = 8000

class MyHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
def do_GET(self):
SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET(self)
# Go to sleep for 10 secs after serving request
time.sleep(10);

httpd = SocketServer.TCPServer((“”, PORT), MyHandler)

print “serving at port”, PORT
httpd.serve_forever()
[/code]

Put this in some directory on your filesystem, in a file named server.py. Now add another file called response.txt to the same directory, containing simply;

[code]
Hello World!
[/code]

Finally add a third file called ajax.html to the same directory, containing the following;

[code lang=”xml”]

Example synchronous

Do it!

[/code]

With that done, you can now fire up the server script – run server.py. For Windows users that’s something like;

[code]
C:\path\to\server.py
[/code]

If you put the python executable in your path or;

[code]
C:\Python24\python.exe C:\path\to\server.py
[/code]

if you didn’t.

The server is now listening on port 8000 so you should be able to access from your browser via the URL http://localhost:8000.

Follow the link to the ajax.html. Now click “doIt” a few times and see what happens – sometimes you’ll get a quick response (an alert that says “Hello World!”). Other times you’ll get a longish wait, during which your browser will be hung up. Now imagine users starting to fidget…

Then, to really see why synchronous requests are a bad idea, try running Apache Benchmark at the same time (it’s provided with Apache 2 as an executable for Windows users) e.g. from a DOS box;

[code]
C:\Progra~1\Apache2\utils\ab.exe -n 50 http://localhost:8000/response.txt
[/code]

Now try clicking on that “doIt” link a few times. Is this something you really want your users to experience?

Otherwise, another thing to try to really grasp the difference between synchronous and asynchronous requests is watching code execute with Venkman.

The bottom line here is remembering the Internet has instability built in – it’s a network you don’t control and can (and will) vary in percieved responsiveness, like when they release the verdict on Michael Jackson, complete with video.

The only two possible exceptions I’d make to this are for an Intranet application, where the end users are in shouting distance, or perhaps in the special case of a sychronous multipart requests (work work only in Mozilla anyway) – see this Sync Multipart demo and notice how the browser “recovers” while the request is still in progress.

So, to repeat, Synchronous Requests == BAD.

15 Responses to Synchronous Requests == BAD
1. […] Never mind my thought about synchronous requests: Synchronous Requests == BAD | Ajax Blog http://ajaxblog.com/archives/2005/05…s-requests-bad Keith D Commiskey http://kdcinfo.com […]

2. […] domani (giornataccia) > faccio ulteriori prove ………. Prima, però, leggiti questo: http://ajaxblog.com/archives/2005/05…s-requests-bad […]

3. […] Synchronous Requests == BAD […]

4. […] Synchronous Requests == BAD […]

5. AmexCredit Card
December 12, 2007 | 3:17 pm

Hello, everybody! Iâ€™m opening a new business, itâ€™s small, so I need a reliable web source to apply for a card. Iâ€™m asking everybody around. Do you know something about

no interest life of card discover

G7tb8Hjk

6. bernita
December 12, 2007 | 10:48 am

It is very important to have good or at least decent credit history if you want to be approved for any kind of credit. Your credit report is the document that shows your creditworthiness. Iâ€™ve been working hard on my credit history – paying my bills, keeping my income stable and Iâ€™m really hoping to be a proved for a good credit card deal at

low apr discover cards

7. christal
December 11, 2007 | 10:25 pm

Most of college students are immature and apply for credit cards without thinking how they will pay there debt back. By the way, most of them are already in debt with there student loans. They shouldnâ€™t listen to those guys running around campuses offering credit cards but carefully compare the offers on professional websites such as

zero balance on transfers good credit

8. […] Synchronous Requests == BAD […]

9. […] Synchronous requests are bad […]

10. ajax-tr.com » Asenkron ve Senkron Meselesi
February 3, 2007 | 10:33 am

[…] Synchronous Requests == BAD […]

11. ativan
June 8, 2006 | 7:29 pm

ativan…

12. Graham Leggett
May 30, 2006 | 7:04 am

I too cringed at the blanket statement “synchronous requests = bad”, because when you genuinely need synchronous behaviour, this behavior doesn’t work properly.

We have an app developed for a client, which, based on the actions of the user, makes SJAX calls that reconfigure the structure of the page before the user can continue. The problem is that our “page restructuring” is atomic in nature – the end user needs to be prevented from manipulating controls on the page until the SJAX is complete, or we have races – a perfect candidate for SJAX.

The trouble is, although HttpXmlRequest supports the “synchronous” flag, an attempt to use it where a server failure is happening causes the entire browser (Firefox, IE6) to hang. Not just the page content (as expected), but the browser as a whole, menus, the works.

The “synchronous = bad” argument has meant these browser bugs remain unfixed, and so we need to build a kludged “hidden overlayed window” technique built on top of AJAX to give us the behaviour that we require.

This could have been avoided if SJAX worked properly.

13. John
March 16, 2006 | 3:33 am

Just stumbled upon this while doing some searching…

Whenever someone gives an open-ended blankent statement such as “Synchronous Requests == bad” it makes me cringe a bit ðŸ˜‰

In addition to your exceptions, there are other (probably rare) instances when a synchronous request might be handy.

For example: I recently had a little project where I needed to retrofit a simple HTML form that POSTed to an existing webservice. I had no control or ability to modify the destination of the POST and the requirements called for me to basically intercept the POST request, issue my own web service call to a different web service and then let the original POST request continue if my new web service call was successful.

One of the simplest ways to do this was using a synchronous XMLHTTPRequest call. Essentially, it allowed me to put the form submission “on hold” while I issued my SJAX request which eventually returned true or false to continue or abort the original POST.

I suppose I could have done it asynchronously, but that seemed like it would do nothing other than take something simple and make it overly complicated.

Anyway, just my 2cents. Great site!

14. […] puts it in far more succinct terms than I’ve been cautiously trying to do in some of these blogs. The more I think about it, the more it’s clear that some kin […]

15. […] rther compounded by developing on localhost where you don’t get to see the impact of synchronous requests, for example, when the network or remote server is taking a […]