I wish it was just the script loading and the other stuff was in a separate library. For a script that purposes to make less loading times I find it ironic that it would also throw in the kitchen sink.
The idea seems nice, I'd have to test it out to actually see if it really delivers. One thing that bugs me tho is the tone of the text. It's all "this is the best thing since sliced bread" and "authors surly must be at least demi-gods". This comment in the page's source says it all really:<p>"headjs :: possibly the most important script after jQuery"<p>I'm all for cocky and confident attitude, I just think it has no place in a presentational web page/docs
I don't understand the whole dynamic class selectors for "Screen size detection". If it's trying to add support for standards, it should support media queries instead.
I've been reading up alot on javascript loaders lately to see which one I should use in the webapp I'm currently building.<p>So far I'm checking out LABjs, RequireJS and now apparently headjs. Unfortunately I am not so sure which will suit me best. Has anybody had any luck with any of the aforementioned three?
If most of your javascript is made up of libraries like jQuery wouldn't it be simpler to use a free CDN like Google or Microsoft so that the library is most likely already on the user's machine? That would appear to be have a better payback than adding another library to load.
IMHO, websites should include a single js file. In development you can have 100 js files, but in production these should be combined into a single file.<p>The downside is that you might include things you don't need in all pages, but that's not an issue because the file is transferred once, and cached. This will also minimize future conditional GET requests that check wether the cached file has changed or not.