I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.
From Require.js - Why AMD:
The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"
I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.
Here's my current JS development work flow.
When in development-mode, all scripts have their own tag in the DOM.
<script src="depA1/dep1-for-module-A.js"></script>
<script src="dep2-for-module-A.js"></script>
<script src="moduleA/moduleA.js"></script>
<script src="dep1-for-module-B.js"></script>
<script src="module-B.js"></script>
<script src="moduleC/module-C.js"></script>
<script src="script.js"></script>There is no abstraction layer. This allows me to better debug individual files. The browser reads separate files, so I can debug with Developer Tools. I like how it's straight-forward.
Dependencies are basically managed right here. depA1 needs to be listed before moduleA. It's explicit.
Modules are 'transported' by attaching to the global namespace.
( function( global ) {
var dep1 = global.depA1;
var dep2 = global.depA2;
function ModuleA() {
// ...
}
// export
global.ModuleA = ModuleA;
})( this );All scripts are concatenated and minified. One HTTP request on load.
<script src="site-scripts.js"></script>The Concat + minify task is maintained separately. It's part of a build process. Makefile or what-have-you. For dependency management, the ordering of scripts matches how they were listed in the HTML.
This can be done easily with some sort of configuration and templating. For example, by setting prod_env config variable to true or false, the site is either in production, serving the one file, or development mode, serving every single file.
{% if prod_env %}
<script src="site-scripts.js"></script>
{% else %}
<script src="dep1/dep1-for-module-A.js"></script>
<script src="dep2-for-module-A.js"></script>
<script src="moduleA/moduleA.js"></script>
...
{% endif %}- What benefit does require.js provide over this workflow?
- How does require.js address minimizing HTTP requests? Is this any better than concat/minifing all the scripts?
Yet another issue with require.js and the like: The DOMContentLoaded-event fires as soon as all the originally embedded scripts have loaded and the original DOM of the document is present. Since injected files or scripts loaded via XHR are not included in this, they will not be present at this time. This results in breaking the load process and deferring the time the page is ready, effectively leading to longer page load and parsing times. Even more, the scripts will compete for network-slots with other embedded assets (images, fonts, etc), slowing them down yet again.
So JS is NOT where you should manage your dependencies, use build-tools or server-side includes to manage them.
Regarding page load times, attempting to handle dependancies via JS always comes at the expense of your users and the general performance of your site. Especially, if the actual page is to be rendered via JS, resulting effectively in a second load cycle for the assets inlined by the generated code. Using some partials loaded via XHR would result in a third cycle and so on.
(Remember late 1990s, how fast the web used to be then?)