One of my co-workers is thinking that it is simpler to just include the document.ready() calls (MULTIPLE) for jquery anywhere in an html document, rather than trying to have them all in the head, foot or in an external js file. Can you give me your thoughts about this?
The document.ready stuff is loaded by modules that are included in a main template. I think this is messy. But I need a good argument point.
If it's not single page specific, I wouldn't recommend it because maintenance is going to be a pain. If it is page specific, it can be better to place it as low in the document as possible, especially if it loads external scripts. Check out Cuzillion, a tool that helps you find the best combination for loading times.
There are a number of problems with your coworker's approach:
If they're in the document itself, you can use server-side variables in the javascript itself, if your page is dynamic (php, asp.net). This can be very handy, but it prevents the javascript from being usable outside the page as a standalone. But if you're sure you're never going to need that javascript outside the page, that's definitely an advantage.
Your coworker's approach is actually quite reasonable and pragmatic.
For the sake of completeness I'll point out that putting too much in ready() in the external JS file is a mistake. I started doing this once and ended up with a page load time of 500-1000ms with all this unnecessary JS code that was being executed. The external JS file(s) should be for declaring functions. The page itself should declare which of those things to actually run. This combines the best of minimal code execution and maximises caching (since the JS file is the same for all your pages).
At the top of the page you don't know what modules/components will be included in the document unless you declare it there as well, which (imho) is a worse case of repeating yourself.
The ideal approach would be some sort of multi-pass templating process that would allow included modules/components to trigger code that needs to be run and your template processor will combine all that and put it at the top of the page. I've actually written systems like this and it is quite doable but it's also more tedious.
You say it's messy but the other side of that coin is that when you look at a page it's easy to determine what code belongs to which module/component because they're adjacent. If you had a big blob of JS at the top of the page, how do you know what relates to what?
As long as you don't end up with dozens of script blocks I think your cowowrker's approach is fine. Any alternative needs to be just as clear and not execute more code than necessary.
It depends.
One motivating factor for putting Javascript in the body is for progressive loading. If the Javascript is just before the </body> then it'll be downloaded last. In fact, even Google Analytics recommends this approach when including their tracking snippet.
However, most of the time even if you're worried about progressive loading you should use an external js file. External js files can be cached aggressively to save bandwidth so they're generally preferred. The only exceptions to that are when it's a small piece of Javascript that only one page uses, or if the Javascript itself needs to be created dynamically with a server-side language and writing it inline is just plain easier to do in that case.
EDIT:
There are multiple ways to do whatever you're doing, I'm sure. And I don't know what you're doing exactly. But since you mentioned Javascript next to every module, that gave me an idea. You could create unique id's for a div around each module. And then you could have a js file which performs operations on each module by those div id's (via a jQuery selector). That'd be a very jQuery-able solution.