If you try to bake a cake with a hammer, you may come away with the conclusion that hammers are useless. Try it with some nails first.<p>For our application, every page has a defined JSON file with dozens of resources that the page uses. CSS and Javascript.<p>When the user asks to load a new page, the loader clears the DOM, fetches the JSON (if it hasn't before), and loads and executes the necessary resources.<p>This reduces the amount of data transferred from the server, since only the necessary files are loaded for each page. They are loaded only once, since the loader keeps track of what it already fetched. On top of that, HTML is only fetched once from the server. After that, it's all DOM manipulation.<p>Seems complex? Sure, if you only have 100K in JavaScript. If you have 2MB, it's really the only way to keep things sane.<p>For each job, a proper tool.
This misses the main point of javascript loaders. The idea is that you take all the scripts that are not essential for immediately rendering the page, and tell the browser that it is okay to render the page before those scripts are loaded. The point is not for those scripts to load faster -- it is to let the user see a rendered page faster.<p>For example, third party javascript files for social media sharing and liking buttons often take a miserable amount of time to load. Bringing them in asynchronously can dramatically improve the user experience of a site because the user doesn't have to wait for them to load before seeing the real content.<p>A similar reason is part of why tables are a bad layout strategy for content in HTML. Back in the day, some (all?) browsers would not render a table until everything in it had loaded. So if you put your entire page in a table, and that table had a big image, the image would block the rendering ofthe page.<p>That is what javascript loaders are about. Non-blocking loading of not-immediately-required resources.
Deferring javascript loading definitely makes sense when you're loading a really heavy chunk of script that doesn't need to be around immediately. I saw load times drop from ~500-600ms to ~150ms with use of LABjs, as the server was rendering the page almost entirely (syntax highlighted client side) but the page editor component (ACE + jQuery + other dependencies) was a good ~500-600kb of javascript for the browser to parse and run, but having the edit button appear half a second or later after the page shows isn't a real problem. ACE loading a full editor as well as syntax highlighting a few 100kb of text on the page isn't a light task.<p>If your site is rendered client side with backbone and templating etc, then there probably aren't many gains to be had there.