JavaScript Module Pattern

javascript module pattern

The JavaScript Module Pattern is another common way to organize code in your JavaScript applications. It was in fact Doug Crockford that first brought widespread attention to this pattern, and to this day, it remains in widespread use in the JavaScript ecosystem. Just like in our prototype pattern tutorial, in this article we’ll have a look at what is good and bad about the module pattern in addition to it’s general structure. Once you’re familiar with this pattern, you will likely spot it in many popular open source JavaScript Libraries currently available.

The Module Pattern’s Claim to Fame

When you are programming in an object oriented language that offers specific keywords to allow for encapsulation such as public, private, and protected, it makes it very clear how to lay out a program and set up the proper visibility of various properties and methods of objects. JavaScript doesn’t have these keywords, so you might be thinking you are out of luck in this regard. It turns out, you can approximate this functionality by making use of the Module Pattern where this functionality is determined by the pattern itself rather than prefixing with specific keywords. For more traditional OOP programmers, this will be music to their ears. For others, it may not be such a big deal if they already have their own way of dealing with the infinitely flexible nature of JavaScript.

A Drawback of the Module Pattern

The module pattern is great and all, but it does have a couple of drawbacks. The first is that it is not memory efficient like the prototype pattern we look at is. Recall that when we use the prototype pattern, each function gets loaded into memory only once. With the module pattern, this is not the case. Every time a new object is brought into existence via your module, a new copy of any functions in that module get loaded into memory. If you have a module with 10 functions, and you create 10 new instances of that object – you now have 100 functions loaded up into memory. To be fair, JavaScript’s ability to optimize the runtime will mitigate any performance problems you might see, but it is worth noting that this is a significant difference between the prototype pattern vs the module pattern. A second drawback of the pattern is that extending and overriding functionality in the module is lost since we are no longer using the prototyping pattern. In addition, as some members become private and hidden in scope, some developers feel things become more difficult to debug. Again, it’s a matter of just learning all these different patterns, and then you can pick your poison as you see fit. Let’s sum up the pros and cons.


  • Ability to Modularize scripts in reuseable objects
  • Variables and functions are removed from the global scope
  • Ability to implement private methods and expose public methods as needed


  • Functions get duplicated across many objects in memory
  • Hard to extend and override
  • Adds debugging complexity

The Structure of the JavaScript Module Pattern

var Themodule = function () {

    // private variables
    // private functions

    return {
        // public functions

There are a few things to note about this pattern. The first is that you see we apply an uppercase to the name of the object when we define the module. This is a convention to indicate that we should use the new keyword on it when we go to make use of this module in our code at a later time. The very first section inside of the anonymous function we have are where the private variables and functions would reside. Inside the anonymous function, we can see a return statement that returns on object literal. Anything contained in this returned object will be public. Without getting too fancy, we can summarize the pattern as having three main sections.

Module Pattern Sections

  • The Constructor (The named module object and function assignment, may or may not take parameters)
  • The Private Members area (everything that comes before the return keyword)
  • The Public area returned by the object literal (anything in the returned object is public)

With that, let’s see an actual example demo of this pattern now.

// Constructor Declaration (Section 1)
var Tesla = function (model) {

    // private variable declaration (Section 2)
    var version, speed_checker;

    version = model;

    // private method declaration
    speed_checker = function (version) {
        if (version == 'Model 3') {
            return 'Ludicrous Mode'
        } else if (version == 'Roadster') {
            return 'Maximum Plaid'

    // Public Members
    // Return object literal (Section 3)
    return {
        gofast: function () {
            return 'Tesla ' + version + ' Now going ' + speed_checker(version) + ' Speed!';
        slowdown: function () {
            return 'Applying brakes to slow down from ' + speed_checker(version) + ' Speed.';
        autodrive: function () {
            return 'Time for a nap. Engaging autodrive.'

// calling our module code
model3 = new Tesla('Model 3');

roadster = new Tesla('Roadster');

Click Clear

Note that with the module pattern we do not have access to the private members of the module directly.

model3.version;          // undefined - can not access private area variables and functions
model3.speed_checker;    // undefined - can not access private area variables and functions
model3.speed_checker();  // TypeError: model3.speed_checker is not a function

roadster.version;          // undefined - can not access private area variables and functions
roadster.speed_checker;    // undefined - can not access private area variables and functions
roadster.speed_checker();  // TypeError: roadster.speed_checker is not a function

JavaScript Module Pattern Summary

In this tutorial about the JavaScript Module Pattern, we have seen how the module pattern can be used to provide encapsulation leading to better code reuse, easier maintenance, and the removal of variables and functions out of the global scope. In our study of JavaScript Patterns so far, the module pattern is the first one that provides public and private visibility for our variables and functions, and that is a great feature when you don’t want callers of the module to be able to access specific functions or variables. As we discussed, each instance you create when using the module pattern duplicates the different functions that you define in memory, unlike the prototype pattern which is more memory efficient. We also saw that extending and overriding is no longer an option. This makes the module pattern great for when you want to simply build a means of allowing others to create objects they will use without the need for extension or modification.