

Are JS loaders snakeoil? - PanosJee
https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment-1773156

======
maratd
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.

For our application, every page has a defined JSON file with dozens of
resources that the page uses. CSS and Javascript.

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.

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.

Seems complex? Sure, if you only have 100K in JavaScript. If you have 2MB,
it's really the only way to keep things sane.

For each job, a proper tool.

~~~
ceejayoz
> If you have 2MB [of JavaScript], it's really the only way to keep things
> sane.

"2MB of Javascript" and "sane" read somewhat funny in the same sentence.

~~~
pornel
We're in the era of client-side web applications. If you're building something
like 280 Slides, you may legitimately have 2MB of JavaScript.

However, to download few widgets and +1 buttons on a static blog page, script
loaders are an overkill.

------
jpadvo
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.

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.

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.

That is what javascript loaders are about. Non-blocking loading of not-
immediately-required resources.

~~~
zoips
I think that misses the point of useful loaders like RequireJS or Dojo's
loader. The point of those to enable developers to actually design a modular
system with well thought out and declared dependencies. Without them you end
up designing a system that is wholly dependent on global namespace pollution
and undeclared dependencies. The fact that you get async load is almost
entirely irrelevant and focusing on it screams of premature optimization (aka
fail).

~~~
benatkin
Those don't need to even be script loaders. Stitch and Browserify do the
module stuff just by concatenating them into a script.

They can just be module loaders or module systems.

------
vmind
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.

If your site is rendered client side with backbone and templating etc, then
there probably aren't many gains to be had there.

~~~
pornel
but why do you need LABjs to defer it, rather than simply
`document.createElement('script')` pattern? (or `<script defer>`/`<script
async>` if you're targeting latest browsers)

------
philjackson
Jashkenas is the developer of Coffeescript, FYI.

~~~
RossDM
Seems to be a lot of immaturity in the Github thread, as interesting as the
implications are.

