Skip to content

Instantly share code, notes, and snippets.

@desandro
Created January 31, 2013 20:26
Show Gist options
  • Save desandro/4686136 to your computer and use it in GitHub Desktop.
Save desandro/4686136 to your computer and use it in GitHub Desktop.
Can you help me understand the benefit of require.js?

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.

Development

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

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

Production

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.

Changing modes

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 %}

Discussion

  • 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?
@onigetoc
Copy link

onigetoc commented Dec 4, 2017

What i see it sometime and often, one person develope a small app and use require without knowing why is using it. Just because everyone do it.

@gramacyan
Copy link

My biggest concern about requirejs/AMD and the well-known (distributed) libraries is that they assume the AMD implementation knows how to identify the module. This by using a path/url as identifier.

For example:

/vendor/DistributedLib.js

define([], function(){  
   return {
      use: function() {}
   };  
});

main.js

define(['/vendor/DistributedLib'], function(lib){  
   lib.use();  
});

That's all fine and dandy, but what happens if we concatenate the files:

define([], function(){  
   return {
      use: function() {}
   };  
});
define(['/vendor/DistributedLib'], function(lib){  
   lib.use();  
});

Our dependency suddenly lost it's id! This piece of code no longer works.

The AMD specification allows setting an id as first parameter but I notice no one sets it in their distributed libraries. Most developers assume that if define && define.amd exists we are using requirejs / path-identifiers. IMHO the id should always be set unless it is an anonymous module:

define('DistributedLib', [], function(){  
   return {
      use: function() {}
   };  
});
define(['DistributedLib'], function(lib){  
   lib.use();  
});

Some time ago I created an AMD implementation (smd.js) since I didn't want file-loading. I was pretty baffled to find out that however I followed the spec, 99% of the libraries out there are not compatible. This because of the anonymous declarations.

Maybe I'm totally wrong here (and not seeing the bigger picture), but it seems to me the AMD pattern is not being used properly (unless you are using requirejs-like systems)?

@Skura23
Copy link

Skura23 commented Jul 12, 2019

Hey guys, can we use es6 module as a replacement of require.js in 2019?

@JamesTheHacker
Copy link

No, because the browser doesn't understand ES6 imports like node does.

To the nay sayers ... RequireJS is used in Magento2. A large project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment