Are JS loaders snakeoil? | Hacker News Reader

Are JS loaders snakeoil?

github.com

37 pointsPanosJee16 comments

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.

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

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.

it really depends on the application/site. 2mb of JS is not much when you look at some of the more advanced web apps. also keep in mind this is progressively loaded. initial page request with this design pattern will be minimal.

Along the same lines I would argue that the problem solved by loaders is a symptom of using the wrong tools - too much JavaScript is possibly a symptom of abusing it - instead of client side loader code, why not optimise the data/server behaviour instead for example? Just a thought...

> instead of client side loader code, why not optimise the data/server behaviour instead

This doesn't make any sense for a javascript-based client. The server code by definition is already as lean as it can be, because everything that could be moved to the client already has been.

We can argue about the merits of having a client-heavy vs server-heavy code base, but that's not what this is about.

So, to clarify, my point... Having the client request only what it needs is a valid optimisation, but having the server send only what is needed for a given request can give the same benefit in a different way.

It necessarily depends on the details of the situation, but it naively seems that it should be possible to not have users download 2MB of JavaScript if they aren't going to use it by rearchitecting the data or doing some server work, instead of sending them different JavaScript to manage that from the client. Perhaps even more naively, if this is done correctly it will reduce burden on both the client and the server instead of just the server (provided the cost of the loader is actually mitigated by the savings).

With that in mind it can make sense regardless of whether you favour server or client bound implementations.

I think I understand what you're trying to say. Each page should have predefined javascript collections in the HTML, varying based on the need of the page.

That's fine for a traditional layout, but most client-heavy applications do not load HTML every time a user clicks something. In my case, the application only loads the HTML once, on the initial visit, and from that point, it's all javascript. Re-working things to load HTML on every click would actually make things slower, since it has to fetch the HTML each time. This type of architecture makes a loader necessary.

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.

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

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.

I guess saying "main point" was an unnecessary value statement. Different applications will find different aspects of loaders useful.

I should have said that discussion missed the point(s) of script loaders...

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.

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)

Jashkenas is the developer of Coffeescript, FYI.

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

Reply on news.ycombinator.com