For example, setting up event delegation on enhanced elements is best done in the HEAD before the elements load. If you setup all your user-event listeners in the bottom of BODY then your users will have a short time when they'll be interacting with elements which A) will do the non-enhanced behaviour B) do nothing whatsoever. Neither A nor B is ideal.
Google Analytics is generally the only JS I put in the head. If some code is absolutely required for the page to work though then it may make sense to put it ahead of the content.
What if you are displaying different elements based on the users location/country (eg. currency, contact details), and you use javascript to detect and do this.
You wouldn't want the page to load first and then this appear.
@jaffathecake I supplied a single example. Also, you might have a very javascripty web application that the users will have had the files cached 99.9% of the time so retrieving the files isn't an issue.
So you would delay the whole page just because of some location specific elements? How about render what you got first so the user has something to look at and then fill in your specific bits later?
Possibly. I am just saying that you might have things that are more important to do before the page loads that might warrant putting it in the head. It's not a set rule that javascript in the head is always bad, you just need to know the tradeoff and make a decision.
Sometimes you render content with JavaScript and want to avoid FOUC(Flash Of Unstyled Content) also sometimes you have JavaScript polyfills that you want loaded as soon as possible.
But I assume that in Apple's case, they are doing it even when they shouldn't be.
