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.
<script type='text/javascript'>
function ljs(s){
var a=document.createElement('script'),
b=document.getElementsByTagName('script')[0];
a.type='text/javascript';
a.async=true;
a.src=s;
b.parentNode.insertBefore(a,b)
}
var Ready=[];
</script>
Then anywhere in the <body> or in any included scripts you can do:
Ready.push(function() {
//this will get executed after all the ljs files
});
Then in a script that contains your JS library, append:
$.ready(function() { // or some other ondomready fn
// execute all the Ready functions
for (var i = 0, m = Ready.length; i < m; i++) {
Ready[i]();
}
delete Ready;
});
The latency difference between an HTTP req for a 2.3K script and a 500 byte script is pretty trivial. And if you're concatenating with other js assets on your site, the incremental increase in size after minification/gzipping will probably be even less than 2.3K.
You don’t understand the philosophy and failed to realize there are already number of scripts that already do this. (Let’s ignore that you you referred to 2K as “the kitchen sink.”)
However some things need loaded in he head (for using HTML5 tags in IE, for example).
Thus there are obvious efficiencies to be gained by essentially hybridizing Modernizr.js and LABjs.
I’m now watching head.js on GitHub, and suggest you reconsider before dismissing it out of hand…
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:
"headjs :: possibly the most important script after jQuery"
I'm all for cocky and confident attitude, I just think it has no place in a presentational web page/docs
The presentation is there to convince you to use their script. I think more OSS libraries and software should convey such an attitude; I'm way more inclined to use software when the authors tell me that it's awesome and why.
I'm the author of headjs. Have to say here that the release date of this tool was supposed to happen much later. yesterday I came back to github on my regular visit and noticed that it had 100 followers! It was OUT. I don't know how.
anyway. I now stopped all my other work and start focusing on headjs. the bugs will be fixed.
BTW: the loader part of the tool can be used as standalone. Here it is:
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.
Your response would be appropriate if we were talking about a new browser but the fact is, virtually no non-Webkit browser, especially on Mobile, supports these media queries. Web dev is all about working with the browsers we’ve got, not the ones we want.
I've been reading up alot on javascript loaders lately to see which one I should use in the webapp I'm currently building.
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?
I've used LABjs and it worked great. It's also the most "focused" loader in the sense that it only does javascript loading. RequireJS also includes a module system and some optimization tools. headjs unnecessarily includes CSS feature detection and screen resolution.
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.
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.
I'm not sure I agree with this. I don't think a user should have to re-download all the JS on the site if I just change a single line. Small changes probably happen frequently and shouldn't invalidate the entire JS cache. If I were using a framework like jQuery, I would link that separately from a 3rd-party CDN like Google. Then all the shared behavior would be another request, and page specific code a third. In most cases I would be changing the page specific code which would only invalidate the cache for that request on that page. IMO that's a better compromise.
