The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

When scripts are loaded in the head, all loading of other elements is delayed until the script has fully arrived. The bigger the script, the longer the wait until people see anything.

When scripts are loaded from the end of the body, the delay before something appears will be noticeably shorter.

Sometimes you will want things to be done when the dom is ready, but before things like images have come down. Placing the script right at the end ensures that the dom is loaded and you don't need onload or onDOMLoad, because the dom will have just been loaded and be ready for anything in your script, while the other elements on the page get loaded.

Let's hear that again. onload and onDOMLoad are not required. Scripts at the end of the document are automatically at the onDOMLoad situation.

I prefer to place the JavaScript entirely in the head of the page coded so as to update the HTML within 1/10th second of the appropriate DOM element being available. Since I also try to keep total page sizes under 40k (80k absolute maximum) any delays caused by loading the javaScript are minimal.

The method offered in the article looks like a practical alternative which solves several issues when you use huge JavaScript codes but at the expense of its not being quite so unobtrusive. The document.write is completely unnecessary though as that is the perfect exception for using a <noscript> tag to insert the style override in the opposite direction.

@felgall
The only way to get a front loaded js function to act on DOM elements as they are loading is to use a setTimeout() for every 1/10th of a second (in your example) that then has a clearTimeout() after the function succeeds. Not a very elegant solution, and it could be resource heavy in many implementations.

Also, when using a strict DOCTYPE, <noscript> fails validation when used in the <head> (as it is a content block), and since we are typically adding stylesheet information, we want that data in the <head>. And the argument for using the document.write in the article is to keep presentation data within the presentation layer, not to muddle it up with the content.

@Ara
Nice article. It is so easy to find bad javascript implementations in the wild, and its articles like this that get developers thinking about the entire pie when they start a project, instead of just their slice.

Also, as far as validation is concerned, developers will need to escape the last ">" character in the document.write in order for the W3C page to give you the thumbs up (a slight bug in their implementation).

Also, when using a strict DOCTYPE, <noscript> fails validation when used in the <head> (as it is a content block), and since we are typically adding stylesheet information, we want that data in the <head>. And the argument for using the document.write in the article is to keep presentation data within the presentation layer, not to muddle it up with the content

I'd forgotten about that. There is never any need to use <noscript> in the body of a web page any more so that particular usage in the head of the page would be the only time where it would be useful to be able to use it.

Also a three line loop using timeout does not slow the loading of a reasonably sized web page significantly. It's only when you go for gigantic sized web pages that it would make a difference (say over 80k in total page size).