The case for RequireJS, part 1

RequireJS is a javascript module created by Andy Chung James Burke. It’s a browser implementation of the commonJS asynchronous module definition. In other words, requireJS let’s you define modules, and then load them asynchronous. Because of this RequireJS allows you to create more reliable and better structured applications.

Away from the global

The two most important methods in requireJS are define() and require(). With define() you can tell requireJS that you have a module for it, which dependencies it has and (optionally) how it should be referred to. With the require method you can asynchronously get modules and then use them in your application, like this:

home.html

<script type="text/javascript">// < ![CDATA[
  require(['myModule'], function (myModule) {
    // do stuff
  });
// ]]></script>

myModule.js

define(function () {
  // my module is created here
});

The most important reason to use requireJS is that it allows you to build your entire application without ever putting anything in the global object. This is crucially important because everything in the global can be effected by other scripts. Because quite often you won’t know what other scripts might run on a page, staying out of the global is the first step to ensuring the stability of your application.

Not storing your application in the global even allows you to have multiple versions of the same module on a page. Something that can’t be done with libraries such as jQuery. If one part of your page depends on jQuery 1.2, you can’t create a script that utilizes features of jQuery 1.3 without upgrading all the other scripts on the page. Which is in the best case unwanted, and in the worst case impossible as the script might be owned by a third party vendor.

The problem of dependencies

Most javascript applications these days are written in a single file. This can be important for performance reasons, but is a nightmare for scalability. The most important reason why this is done however seems to be the issue of dependencies.

In javascript it is difficult to be sure when things are loaded. It’s also difficult to load extra files on the fly and to detect when the modules you need have become available. Therefore it’s quire rare for scripts to have dependencies. And if they do, it’s rarely more then one; the library they were build on. This of course results in bloated libraries and frameworks that attempt to cover for every possible use case, and bloated javascript files which become difficult to manage.

Application structure with requireJS

In most programming languages it’s common practice that every class in the application is given it’s own file. There dependencies are defined at the top, and they are structured/packaged in such a way that they are easy to manage. This helps to keep a project maintainable.

CommonJS has attempted to create that same structure for Javascript. And although it’s primary aim (at the moment) is on the server, it’s specifications can in some cases also be applied client side. Which is what requireJS has done.

RequireJS ensures that your modules are loaded and run in the correct order. It makes it easy to separate different modules into different files. And this in tern helps maintain different versions of your software. RequireJS will load all dependencies for a module and then pass them as arguments. For example:

// myModule.js
define(['myModule/Foo'], function (Foo) {
  // use Foo for myModule
});

// myModule/Foo.js
define(function () {
  // define Foo
});

In the next part I will take a look at the difference between RequireJS and other javascript tools.