Require.js is well covered ground. Smarter people with more experience working with it have got the basics at very least sorted. I’d recommend reading some or all of the linked articles for your Require hit, really. This one by Aaron Hardy in particular is wonderful, although only the last page actually covers Require, the whole thing is excellent. So, with the caveat that there are better places to get this information in place, what is Require.js?
What is Require.js for?
So why use it?
It also kills the risk of accidentally introducing an unintended dependency. I won’t start referencing things I shouldn’t just because they are available to me because making them available is an action that requires a moment’s thought (and it really is just a moment).
I haven’t done any tests of the actual effect of this in reality yet, so what follows is really nothing but prejudice and a resistance to change. Loading modules asynchronously like this means adding a huge number of extra http GET requests to your page load. Sure each file is coming down quickly, but that goes against
everything that I’ve been taught about web performance – keeping requests to a minimum. However! Require even has suspicious curmudgeons like me covered too.
Part of the attraction of Require over alternative AMD loaders is its optimizer r.js. This can be used before serving your code up to minify, obfuscate and concatenate your modules. So far my only success has been bundling everything into a single file, but I understand it is possible to configure it so that you produce a site-wide bundle and a separate bundle loaded separately for every page. This is my preferred solution based on no actual testing. Fortunately though, once I’ve worked out how to make it go, it should be easy to try all three of these options without impacting the actual code. This flexibility makes me happier than is reasonable.
Next time: details of how to use Require (Spoiler alert: It’s really easy).