Adding Structure to Your JavaScript Projects With RequireJS

RequireJS is a JavaScript utility for module loading and dependency management. It enables you to keep independent modules in separate files, and automatically loads the defined dependencies between them. This gives the notion of an “import” and, in theory, leads to more maintainable JavaScript.

Modules can be thought of simply as blocks of code executed under the context of the namespace in which it is defined. By default, this is the filename without the extension. In the example below, calling define in the dinner.js script will create the dinner module. The return value of a module can be used by any other code which depends upon it.

It is important to note that keeping the JavaScript files separated will negatively impact your page load speed. With a RequireJS workflow, you will want to use an optimization tool (r.js) during your production deployment process to concatenate and minify your code to a single, small file. You can read more about this in the “Further Reading” section below.

An Example

Let’s take a look at a very simple example of RequireJS in a web application.

Imagine we have the following project structure:

  • index.html
  • js/
    • main.js
    • dinner.js
    • meat.js
    • potatoes.js
    • require.js

We will want to start by adding a script tag to our main page to load the RequireJS library. We will also specify an entry point through the data-main attribute.

<!doctype html>
    <title>My Dinner Example</title>
    Total meal calories: <span id="lblCalories"></span>

    <a href="http://js/require.js">http://js/require.js</a>

This entry point will load the js/main.js script automatically. From our RequireJS scripts, we can either define a new module or use require to load dependencies without defining a new module. In either case, loading dependencies is done using the function call, as seen below in dinner.js and main.js:

// meat.js (potatoes.js would be nearly identical)
// Define a new module named "meat"
define(function() {
    return {
        calories: 350
// dinner.js
// Define a new module named "dinner"
define([ 'meat', 'potatoes' ],
function(meat, potatoes) {
    // Do something using meat and potatoes
    return {
        totalCalories: meat.calories + potatoes.calories
// main.js
// Load the dinner module
require([ 'dinner' ],
function(dinner) {
    document.getElementById('lblCalories').innerHTML = dinner.totalCalories;

To load other modules as dependencies, pass an array as the first parameter with a series of modules to load. In the main script, loading ‘dinner’ will call the dinner.js file, which returns an object containing the totalCalories property. Since our meat and potato modules do not depend on anything else, we can omit the first parameter. In the main script, I use require because I want to depend on modules, but I do not want to have main itself be used as a dependency elsewhere. Use the define method instead when defining a module. By default, the module name takes the name file minus the extension, so you should only define a single module per file.

There are several ways to call the define and require methods, including the option to specify a custom module name. To learn more, read the API documentation for define.

Further Reading

For a more thorough walkthrough of RequireJS, read through the API documentation. For instructions on how to concatenate and minify your RequireJS projects, refer to the optimization instructions. To simplify the build process, you may find that using a tool like grunt.js can be very helpful.

RequireJS is extensible, so there are a variety of plugins you can use to extend the capabilities of the module loader. For example, if you want to load CoffeeScript, you can use the require-cs plugin. If you use a templating library like mustache.js, you can use the text.js plugin to load static text resources to avoid writing your templates as JavaScript strings or between “ tags.

To see how RequireJS is used in an existing project, check out my “ToupĂ©e” project on GitHub, which uses RequireJS with Backbone.js.


RequireJS removes the guess work from dependency management, meaning you can worry less about the order your scripts are loaded and where you define your functions. By separating your modules into separate files, you create a separation of concerns and avoid the possibility that your application’s main script grows too large to manage.

Static Site Generators

As web developers, we most often work with dynamic web content. These days, it’s rare to come in contact with plain old HTML files. That said, there are a growing number of tools which assist in the creation of static sites, aptly named static site generators. To cite a recent example, Kyle Rush published an article explaining how Obama’s campaign team used Jekyll, arguably the most popular static site generator, to improve the performance of their $250 million fundraising platform. In this article, I will discuss the purpose of these tools, the benefits they provide, and several popular options to choose from.

An overview

For a simple site or blog, it is not uncommon to create a basic web application consisting of two primary components: (1) a page layout (i.e. header and footer), and (2) a small collection of database tables to manage content. There really isn’t a whole lot going on here, and the whole application server + database + hosting solution can become a real pain for such a simple project. If the goal is to simply wrap written content within the context of a master layout, this is hardly the simplest solution.

Static site generators are able to satisfy the same needs without the unnecessary complexity. As part of the build process, layouts are combined with content to generate simple HTML files. Layouts are likely to have some variation of a templating syntax, and content files can be written in Markdown or other familiar writing formats. As a result, you avoid the headache of the overhead which can accompany dynamic sites.

Primary benefits

  • Fast: Because the generated files are simple HTML files, they can be served directly rather than being processed by an application server.
  • Affordable: There are several options to host your static sites for free. For example, you could store the files in a simple Dropbox folder, and use a service like site44 to serve them from a custom domain. You can also serve a static site directly from a GitHub repository using these instructions. For a more sturdy hosting solution, Amazon offers their Simple Storage Service (S3) at a very affordable price for most sites.
  • Simple: Most static site generators require a layout, some content, and a basic understanding of the syntax used to link them together. Jekyll uses Ruby, but you won’t need to know much about Ruby in order to use it for your own sites.
  • Secure: Because your site is simple HTML, there’s significantly fewer security risks. As a result, you can concentrate on what really matters: the content itself.

Popular Static Site Generators

Depending on your development environment, you may want to choose from one of the popular options below:


This blog itself was previously maintained using a custom static site generator. It’s fairly basic, but the source code is available at the GitHub repository in case you’re curious about the project structure of a simple static site. Since this is a custom generator, it may be more relevant to refer to the source of some of the many sites which use Jekyll.