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;
# minimal web server. serves files relative to the
# current directory.
# See: http://effbot.org/librarybook/simplehttpserver.htm
# IMPORTANT QUOTE:
# “[the basic SocketServer implementations] process requests
# synchronously; each request must be completed before the
# next request can be started.”
PORT = 8000
# Go to sleep for 10 secs after serving request
httpd = SocketServer.TCPServer((“”, PORT), MyHandler)
print “serving at port”, PORT
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;
Finally add a third file called ajax.html to the same directory, containing the following;
With that done, you can now fire up the server script – run
server.py. For Windows users that’s something like;
If you put the python executable in your path or;
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
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;
C:\Progra~1\Apache2\utils\ab.exe -n 50 http://localhost:8000/response.txt
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.