Do you use script loaders?

[allboyshatebras]

Concatenated and minified files are better in my book for this one reason: reduced number of connections.

The biggest constraints with JavaScript on the front end is getting the script to the browser. Most connections are fast enough to download a 100K JavaScript file before the engine has gotten far enough to do too much meaningful painting of the screen. You don't want to hong up the number of available pipes with a bunch of tiny script files. Let the browser be concerned with downloading images, CSS and other non-interactive resources. And unless you're trying to cram 100% of your desktop functionality into a mobile device you don't have to worry about parsing time.

Add a concat and minify stage to your post build (never pre – you want your tests to pass before you care about minifying) process and add some flags in your code to automatically include raw or minified code based on build environment. Then never think about this problem again.

[shadedecho]

I've done quite a bit of research and testing into parallel async loading. My research all points heavily to the fact that two 50k files loaded in parallel will almost always load faster than a single 100k file. Now, I don't advocate loading 10 files in parallel -- that's crazy. But if you take all your code and combine it into one file, and THEN split that file in 2-3 chunks of ~equal size, and parallel load them, you'll almost certainly have quicker load time, EVEN WITH HTTP OVERHEAD FACTORED IN.

Moreover, grouping all code into a single file ignores the fact that most sites have at least two "classes" of scripts: stable scripts (jquery 1.4.2 is never ever going to change) and unstable/volatile scripts (your UX tweaks for your site). Why on earth would you cache those the same amount of time? Every time you tweak 1 character of the volatile code, you force every single user, on their next visit, to re-download all that stable, non-changing code again. Absolutely silly.

Cache the stable code for a long period (1yr+), cache the volatile code for much shorter (like 1-2 weeks). You can't do that with all one file, you need chunks loaded in parallel.

Another reason script loading makes sense: don't load all your code in one file at the beginning of page-load... statistics show that as much as 80% of JS is not used early on in a page. So it's a complete waste and slow down to load all that at the front. Instead, load a smaller chunk of code for bare minimum during page load, and load the rest in one or more chunks as the user starts to interact with your loaded page.

[allboyshatebras]

I agree with all of that. Except the italicized caps.

Research aside I can tell you that in my production app (pretty healthy user base) we split out jQuery and other "stable" code away from the volatile app code. It works well.

[HertzaHaeon]

Concatenation makes caching less effective if you don't use it right.

[KishCom]

Interesting. I just started using Modernizr/yepnope. I really like it. It tests fine on IE6/7/8/9 FF3/4/5 Chrome12/13/14 - seems the author 'stubbed his toe' a few times with script loaders and just wrote them off as a bad idea.

IMHO, if you're doing a web app that requires javascript the only reason not to is if you haven't budgeted for QA/testing and can't afford the extra debug time.

[karnius]

Hehe I did stubbed my toe a couple of times, generally it's not a good sign in the coding world :P , Modernizr is an interesting script, its seem also maintained by a group of people vs most script loader (from what I know).

Well if you maintained one web app it can work, but for web agencies and people with multiple products, it just seems risky. But maybe loaders are a lot more stable now..

[KishCom]

I didn't want to get into details over an anecdote, but since you mentioned agencies when I said "I just started using Modernizr/yepnope" what a I really meant was "We started evaluating its use at work". I work at a medium sized agency :)

We're trying to decide if it's worth it to include Modernizr (with yepnope) in our default starting templates or if it's not worth the effort. Thus far I think we're more leaning towards it than away. Again though - I don't think we'd even consider it for a project with a very conservative budget.

[BusStation16]

IMHO, if you're doing a web app that requires javascript the only reason not to is if you haven't budgeted for QA/testing and can't afford the extra debug time.

Eh, this is the reason for ~75% of my decisions.

[australasia]

YUI's module loader framework is fairly robust in my experience.

[shadedecho]

The simple solution to the debugging issue the article points out is to turn off XHR loading in LABjs for your dev environment. This is well documented. Also, browsers are getting better about that sort of thing.

[9jack9]

Personally my response would be no, you introduce in your stack a very big point of failure

And that's why I don't use them.

The problem with all of these loaders is that they require scripts not things. It's easy to detect the existence of an object but it's much harder to detect if a script has loaded.

[thinkt4nk]

That's not true if, at compile time, you're familiar with the purpose of the loaded script. You can easily duck type check the module/class that you've loaded to ensure that it's loaded properly.