This page contains an external script and some inlined code that depends on the external script.
The external script, menu.js, is loaded in the normal way: <script src="menu.js"></script>.
The inlined code's init function calls EFWS.Menu.createMenu(), a function defined in the external script.
The nice thing about loading the external script the normal way is that execution order is preserved across all browsers. The external script is downloaded, parsed, and executed. After that, the inlined code is parsed and executed. There are no race conditions.
The downside of loading scripts the normal way is that they block the page in two ways: downloads and rendering. In many browsers, once a script starts downloading, the browser won't start any other downloads. The external script on this page takes 2 seconds to download. There's also an image that takes 1 second to download. On most browsers, these two resources are downloaded sequentially. So the image's download time will be about 1 second after the external script's execution time.
What we want is for the script and image to download in parallel. Some newer browsers tout parallel script downloading. While it's true they might download a few scripts in parallel, they generally still block when downloading other resources. (See Chapter 4 from the book for more details.)
Downloading scripts the normal way blocks rendering in that any elements that occur in the page below the script aren't drawn until the script is done downloading. In this page, notice these paragraphs of text don't appear for two seconds, even though the text is downloaded first as part of the HTML document. The reason they're delayed for two seconds is that's how long it takes for the external script to finish downloading.
In order to address these blocking issues, we want to find ways to load scripts without blocking. Luckily, there are advanced techniques for loading scripts that avoid this blocking behavior. Use the other examples above to see how these techniques perform.