is a pretty simple concept, so you might wonder why this would even be an issue. The answer may lie in the design of early browsers, as well as the more modern browsers that were derived from them. Asynchronous communications has always been essential to Web technology. When a browser loads a Web page, it finds tags that instruct it to load other itemsimages, applets, frames, scripts, and so on. These items, of course, can be on other servers. Because the browser is loading a number of items from potentially different locations, it loads them asynchronously and in parallel. That way, you can see the Web page that you have loaded from a very fast site, even while waiting for a huge image from a slow site to appear inside that page.
Browsers are so carefully built around asynchronous interaction that it can be tricky to force synchronous loading. If you've done any client-side Java programming (especially in the early days of Java), you probably remember how complicated image loading was. You couldn't just call a function that returned a fully loaded image. Instead, you would initiate a load, and the loading process would invoke callbacks to inform you about the progress of the load, culminating in a final message that told you everything was loaded.
Many programmers wrote their own libraries to take care of all of this (sometimes using threads), so that they could just call a function that returned a fully loaded image. But it was easy to get this code wrong, especially when trying to run the code on different platforms with different patterns of I/O behavior. Finally, such functions moved into the standard Java libraries, but it took quite a while.
include as we know it from other languages.
You can have one script load another in a number of ways. The most common is to simply write a script tag to the end of the document:
document.write( "<script src=\"mycode.js\"></script>" );
The problem with this is that mycode.js is going to be loaded later. The following example shows why this is a problem:
document.write( "<script src=\"mylibrary.js\"></script>" );
mylibrary_function( 1, 2, 3 );
This code attempts to load mylibrary.js and then call a function from that library called
mylibrary_function(). But the first line only starts the
include. It tells the browser to start loading and then continues to the second line, which tries to call the function. But the library isn't loaded yet, and the function isn't defined. So the call to
This kind of
include, then, is a hack. You'll find some workarounds for these problems as well, such as sleeping or breaking scripts into pieces, but these are also hacks, and they have still more problems of their own.
The XMLHttpRequest Solution
Most AJAX frameworks get around these problems by implementing some kind of
statement. They usually implement it with the XMLHttpRequest object, which is present in the most recent browsers.
eval(), and it's ready to be called.
However, XMLHttpRequest isn't perfect. It exists in the latest browsers, but not everyone runs the latest browsers, so that won't do. And you may be subject to the usual complications caused by different browser implementations.