Code in JavaScript the smart, modular way

Are you a JavaScript hack or a real developer? Use this quick start guide to learn to write modularized JavaScript code

1 2 3 Page 3
Page 3 of 3

CJS (CommonJS)

If you've ever written server-side JavaScript using Node.js, you've used CommonJS modules. Each file you write isn't wrapped in anything fancy, but has access to a variable called exports to which you can assign anything you want to be exposed by the module. Here's what it looks like:

// a 'private' variable

var orderId = 123;

exports.getOrderId = function() {

return orderId;


Then when you want to use the module, you declare it inline:

// orderModule gets the value of 'exports'

var orderModule = require('./order-module');

orderModule.getOrderId(); // evaluates to 123

Syntactically, this has always looked better to me, mostly because it doesn't involve the wasteful indentation present in the other options we've discussed. On the other hand, it differs greatly from the others, in that it's designed for synchronous loading of dependencies. This makes more sense on the server, but won't do on the front end. Synchronous dependency loading means longer page load times, which is unacceptable for the Web. While CJS is by far my favorite-looking module syntax, I get to use it on the server only (and while writing mobile apps with Appcelerator's Titanium Studio).

One to rule them all

The current draft of the sixth edition of ECMAScript (ES6), the spec from which JavaScript is implemented, adds native support for modules. The spec is still in draft form, but it's worth taking a peek at what the future could look like for modular development. Quite a few new keywords are used in the ES6 spec (also known as Harmony), several of which are used with modules:

// libs/order-module.js

var orderId = 123;

export var getOrderId = function(){

return orderId;


You can call it in later in several ways:

import { getOrderId } from "libs/order-module";


Above, you pick and choose which exports within a module you want to bind to local variables. Alternatively, you can import the whole module as if it were an object (similar to the exports object in CJS modules):

import "libs/order-module" as orderModule;


There's much more to ES6 modules (check out Dr. Axel Rauschmayer's 2ality blog for more), but the example should show you a few things. First, we have a syntax similar to CJS modules, which means extra indentation is nowhere to be found, although that's not always the case, as you will find in the 2ality link above. What's not obvious by looking at the example, particularly because it looks so much like CJS, is that the modules listed in the import statement are loaded asynchronously.

The end result is the easy-to-read syntax of CJS mixed with the asynchronous nature of AMD. Unfortunately, it'll be a while before these are supported fully across all commonly targeted browsers. That said, "a while" has been growing shorter and shorter as browser vendors tighten their release cycles.

Today, a combination of these tools is the way to go when it comes to modular JavaScript development. It all depends of what you're doing. If you're writing a library, use the module design pattern. If you're building applications for the browser, use AMD modules with a script-loader. If you're on the server, take advantage of CJS modules. Eventually, of course, ES6 will be supported across the board -- at which point you can do things the ES6 way and scrap the rest!

Questions or thoughts? Feel free to leave a message below in the comments section or reach out to me on Twitter, @freethejazz.

This article, "Code in JavaScript the smart, modular way," was originally published at Keep up on the latest news in application development and read more of Andrew Oliver's Strategic Developer blog at For the latest business technology news, follow on Twitter.

Copyright © 2014 IDG Communications, Inc.

1 2 3 Page 3
Page 3 of 3
How to choose a low-code development platform