Do you use script loaders?

by Cedric Dugas on July 29, 2011

It’s funny I have the impression that script loaders keep coming back in the news, if we go back one year and a half ago we mostly only had labJS and requireJS, these guys want to load all your scripts asynch, but now we got new kids, notably yepnope, that allows you to load scripts based on feature detection and others.. headJS, controlJS, enhanceJS, jsDefer ouch…

Script loaders are responding to a weird problem, you would think that browsers do a good job at loading script since its been doing just that for more than 10 years, but in fact not really, it could be a lot better and this is where those technologies come in.

What they do is super charge the loading speed of your scripts by using various tricks, and when I say tricks, sometimes it really means hacks, specially in older browsers like ie6. In my article about script loaders 1 year ago I gave them praised, and I definitely meant it, but currently I unfortunately just stopped using loaders.

What went wrong?

When I first tested labJS I was flabbergasted, it was loading my scripts 3 times faster on a average website. I was looking at optimizing the front-end speed of our framework at my last job (w.illi.am/ a web consulting/agency), and this was a strong contender at being implemented. And we did just that, we implemented labJS at the core of our CMS. It definitely took some fine tuning and we had some weird bugs at first with execution order and dom ready statements, but within a week or 2 everything was back to normal.

Then a new project came with an IE phase testing, to our horror IE8 was giving us wrong error lines, it did not understand what labJS was doing and could not find any script file loaded by labjs. Still we continued to use it. Then Firefox4 came along, our older labjs version was not compatible with it, this was a big problem for us, since w.illi.am/ does something like 50 websites a year, not centralized. We just could not afford to update labJS for each project. This was the end of script loading for us, we had to revert back to our old way, we could not take the chance that older version would not be compatible with future browsers.

** I also heard that some of them had problems with newer webkit releases, prompting another library update.

Is it really worth it to use a script loader?

Personally my response would be no, you introduce in your stack a very big point of failure, if this script fails, your entire app fails, furthermore you *generally* need to follow convention dictated by the library. RequireJS works best if you follow their module convention, and labJS has an api to make it easier to keep the execution order, but it really changes the way you would normally work.

I’m no more at w.illi.am/, but at Cakemail we are currently minifying everything we can into one big js file, like what javascriptMVC does, and loading it normally. It seems to me as the best approach, *some* scripts minifier have been stable for ages, so I know that my production application will not break because of it (it can happen of course, but it is really rare), and in development we just keep the gazillions of script tags for debugging.

That being said, I still think script loaders are a brilliant technology, and I have a lot of respect for their authors. I mean, if your looking for optimizing your page loading time to the maximum, script loaders are a no brainer, its probably your single best optimization beside doing the normal stuff, but it’s not a task to be taken lightly and you must be aware that there will be maintenance and setup cost.



6 comments

Great post!
I’ve never used library like requireJS or labJS because i was always minifying/combining my js file into a single file for production use.

For the first time in my current project, i needed to load different stylesheet/js to deliver different experience for desktop, tablets and mobile.
The use of Modernizr and YepNope.js was a real pleasure.

At the end, i will still minified my js/css and combined my js file to speed up loading time and request numbers. But the benefits are mainly to load only required file for my different UX.

by Dominic Mercier on July 29, 2011 at 12:24 pm. Reply #

I use my own implementation, because head.js and others are just too big. You can read my opinion about script loaders and why they are still a good idea here

by Oliver on July 29, 2011 at 2:03 pm. Reply #

In a way I’m glad to hear that – on a few recent projects I’ve done the same sort of thing, sticking all the code in one big file to cut request count. Can even the smartest loader really pull, say, 4 25kb JS files into the browser faster than a simple script tag will fetch a combined 100kb file? There’s not much room for parallelism to help there, so I’d expect the extra round-trips to make it a net loss.

Interesting given how Google are pushing their own loader as a way to get jQuery and co from their CDN, rather than simple script tags. Hopefully they’ll maintain it indefinitely to a high standard, but can it really compete with plain old script tags?

by James Sutherland on July 29, 2011 at 3:15 pm. Reply #

@Dominic Make sense if your coding an “hybrid” experience, personally I would probably give an entire different app for mobile vs desktop. So I would no need a script loader for that.

@James It make sense that google load analytic asynch, it’s one of the good use case, you do not control the google script tag, and if the server go down, your website would stop loading at this script tag.

by Cedric Dugas on August 1, 2011 at 9:57 am. Reply #

Using these depends on just how dependent your site is on javascript. Sometimes the hassle of implementing such solutions do not equate to equal gains.

by Luke on August 15, 2011 at 3:27 pm. Reply #

I recently commented as well, loaders are good but not always good:
http://webreflection.blogspot.com/2011/08/once-again-on-script-loaders.html

also yal.js for those who complained about size ;-)
https://github.com/WebReflection/yal.js

by WebReflection on August 19, 2011 at 4:57 pm. Reply #

Leave your comment

Required.

Required. Not published.

If you have one.