Here's another common mistake I see on Stack Overflow from time to time. The basic pattern goes like this:
$('#myElement').load('lipsum.html');
alert($('#myElement').html());
// wtf, it's still empty?!?
This is something that I struggled with when I started playing with AJAX techniques, too. It's quite understandable how so many people run into this issue. I mean, virtually other bit of code you write is executed in the order you write it. You'd expect that the alert() above would be run after load() function has run. Of course, you forget that A is for Asynchronous.
Solving the problem the wrong way: SJAX
The first logical step that many people seem to move to is to avoid the situation altogether. If making an asynchronous call is causing this problem, we'll just switch to synchronous calls - problem solved! This is entirely the wrong way to do it. Synchronous XHR calls will allow the the code sample above to run as the developer would hope, but it has the very nasty side effect of freezing the browser while it waits. No further code is executed until it get the response from the server. This is often overlooked due to poor testing. On a developer's local machine, the request completes in milliseconds and everyone's happy. In real life, a slow connection or an overworked server can render the user's browser useless for 30 seconds or a minute. Depending on the browser, you can't scroll the page, change tabs, open new links, etc. This is probably not the "improved user experience" you were hoping to deliver.
Solving the problem the right way: callbacks
When setting up an XHR call, you are able to specify a function to be run when its status changes. Using vanilla javascript, this can be a pain, but libraries such as jQuery make it much simpler.
"lipsum.html"
, function(responseText) {
alert("Complete! The server said: " + responseText);
}
);
You do have to adjust how you think about your program flow, but once you starting thinking with portals AJAX, you'll never look back.
Addendum
The basic message of this post has been synchronous XHR is evil, but I should mention the ONE place where its use is legitimate: inside onunload events. These events are called when the user leaves the page or closes the browser. If you want something to happen then, such as automatically saving a page, then asynchronous XHR will not help, since the browser closing or page changing will cancel the request immediately. In this scenario, locking up the browser while the request is being processed is somewhat acceptable. Just remember to test that it doesn't take too long!