Learning JavaScript Design Patterns

Chapter 11. Modern Modular JavaScript Design Patterns

In the world of scalable JavaScript, when we say an application is modular, we often mean it’s composed of a set of highly decoupled, distinct pieces of functionality stored in modules. Loose coupling facilitates easier maintainability of apps by removing dependencies where possible. When this is implemented efficiently, it’s quite easy to see how changes to one part of a system may affect another.

Unlike some more traditional programming languages, the current iteration of JavaScript—ECMA-262—doesn’t provide developers with the means to import such modules of code in a clean, organized manner. It’s one of the concerns with specifications that hasn’t required great thought until more recent years when the need for more organized JavaScript applications became apparent.

Instead, developers at present are left to fall back on variations of the module or object literal patterns, which we covered earlier in the book. With many of these, module scripts are strung together in the DOM with namespaces being described by a single global object where it’s still possible to incur naming collisions in our architecture. There’s also no clean way to handle dependency management without some manual effort or third-party tools.

While native solutions to these problems will be arriving in ES Harmony—likely to be the next version of JavaScript—the good news is that writing modular JavaScript has never been easier, and we can start doing it today.

In this section, we’re going to look at three formats for writing modular JavaScript: AMD, CommonJS, and proposals for the next version of JavaScript, Harmony.