JavaScript Programming Patterns

JavaScript is meant to be used to add behaviour to a website, might it be for form validation or for more complex operations like drag & drop functionality or performing asynchronous requests to the webserver (aka Ajax). During the past few years, JavaScript libraries became increasingly popular. One of the reasons is definitely that websites are getting more and more complex and reinventing the wheel each time is not acceptable if you are working on a tight schedule. But letting aside libraries and focusing on the “bare” syntax of JavaScript, it is very valuable to know what kind of options you have in terms of programming patterns when writing JavaScript.

In this article I am trying to present some of the techniques out there that I have discovered. The patterns I would like to mention are the following:

The way I decided to present and compare these different patterns is by solving the same given task with every pattern. The task is: You have three links on a page and when clicking the links, the background color of that link should change to a preconfigured value. The markup looks like this:

To complete the task given, you essentially would need to complete the following steps:

  • Define the background colors in some kind of configuration variable
  • Get all the anchors on the page and store them in a data structure (array)
  • Loop through that array and attach an onclick event to them, pointing to a function that changes the background color
  • If the link gets clicked that function gets executed and the background color of the link clicked gets changed

The Old-School Way

I would like to start off with demonstrating how this task would have been solved in the late 90?s, early 2000. At that time, JavaScript was purely used to do sequential programming, defining one function after the other. Nobody worried about namespace. Nobody worried about re-usability of code. Nobody worried in general, cause each script kiddie was paid a huge amount of money. They couldn’t be bothered with such things. To make everything at least a bit more neat, I decided to use function definitions, even if you could write some of that code straight into the bode of the page (to make things even worse). So you could have 2 functions:

  • anchorChange1: collects the links and attaches the event
  • changeColor1: executes the actual swap of the background color

Without further ado, your final code might look like this:

In a JavaScript block on the page – after the anchor and preferably close to the closing body-tag – you then only need to call the main function:

Please proceed to the working example. It works fine, although it has the problem of cluttering up the global namespace. This means, in a much more complex situation with several developers working on the same project, you have a big problem if someone comes up with something like this:

If that gets defined after your own definition of changeColor1, your code will get overwritten by that second definition of the function with the same name. As stated in the introduction, website projects are far more complex theses day (with possibly several frontend developers working on it) than they were 5 to 10 years ago. So there is a potential danger that someone overwrites somebody else’s code and tracking down that problem can become a pure nightmare. So these days, I believe this technique should be avoided altogether.


The second solution is dealing with the creation of a singleton, which means creating an object and assigning values (e.g. functions) to its properties. This object is immediately available for use and can be created using the following syntax:

For a start, I created an empty singleton:

I decided to create 3 different properties for this object:

  • config: holds the different background colors
  • alterColor: method which does the actual color change
  • init: attaches the alterColor function to the link element

The config property holds the new background colors:

alterColor changes the background color to the new color:

init is responsible for linking the onclick event to the alterColor method:

The final singleton looks like this:

Please proceed to the working example, annotated with some comments.

Module Pattern

Taking the singleton pattern one step further leads us to what Douglas Crockford calls the “module pattern”. The idea is to have an encapsulated module, that cannot conflict with any other modules you or someone else has created. You can create public and private methods within that module.

First, lets create a function that gets executed immediately (which is caused by parens after the closing curly bracket):

As stated before, with this programming pattern, you can have public and private methods. Public methods can be accessed from outside, private methods only from within the object. I decided to have a private variable config, a private method alterColor, which does the actual color change, and 2 public methods, which are bound to the object itself. For this to happen, you return an object with the respective properties:

The alterColor function, as well as the config variable, live within the parent function anchorChange3, but outside the returned object:

As alterColor is a private method, it cannot be accessed from outside. To be able to execute that function you either need to put it in the object (which will basically lead you to using the singleton pattern again), or create another property within the returned object that calls the method. I have done the latter by creating changeColor which then calls alterColor.

The final code for this pattern looks like this:

As with the general singleton example above, in the body of the HTML document you would then need to call the init method:

Please proceed to the working example. The source code is, again, annotated with comments to hopefully make clear what is happening.

Revealing Module Pattern

Based on some investigations on how he could overcome some things he did not like about the module pattern, Christian came up with something that he calls Revealing Module Pattern. As the name indicates, it is related to the Module Pattern, but might be a bit more structured and easier to understand, especially when it comes to handing over code to other developers in your team.

First, it starts again with a basic function, which gets defined and called immediately:

After that, all the properties and methods get defined, without paying attention to whether they are actually private or public:

Now we are getting to the interesting part. Switching back to the original Module Pattern, I am sure you have noticed that it ends with the return statement which holds all the public properties and methods. In the Revealing Module Pattern, you only put references to those properties and methods in there that you want to have publicly available:

The only two properties needed to be publicly available are init (which does all the preparation work) and changeColor (which gets called when an anchor gets clicked). Looking at the code makes it clear right away which properties and methods are publicly available. The final code looks like this:

As with all the other patterns, you need to call the respective function in a script block in your page:

And again, the working example for this pattern.

Custom Objects

The method of creating a new object of a class (instantiating it) is common in all object-oriented languages. But JavaScript is object-based rather than object-oriented. In JavaScript, you just need to call the constructor function of your (custom) object with respective parameters to create an object. You do not have any classes or subclasses as e.g. in Java.

First, we would need to create a constructor function for our object:

We leave the constructor empty for now (which is totally fine), but later on we will add a call to the init method of that object.

Using prototype, we can now add additional properties to the object “blueprint” so that these items are available for every instance of that object right from the start. I ended up with having 3 properties, namely: config, changeColor and init.

As pointed out by Mike West, using prototype is much more efficient than creating these methods “on the fly” every time a new object gets created. The final custom object looks like this:

In the body of the document, you just need to create a new instance of anchorChanger:

As with the examples before, you can check out a live demo together with comments.

Lazy Function Definition

Peter Michaux came up with a pattern that he calls Lazy Function Definition. This pattern is particularly useful when you need to do computations on the page once and then reuse the output multiple times. With this pattern, you ensure that stuff that should be done once, is indeed only done once. The example that Peter is giving deals with putting together a scrolling function based on different browser environments. Based on the browser model, the scrolling function is put together differently when the function gets called for the first time.

For my task, this pattern does not provide a real advantage, cause there is just no heavy or complex computation needed. But how does it work in general? You start with your basic function definition:

The I added the properties, much like I did with the other patterns above:

All the above should only be done once and there is no need to include these properties in subsequent calls to that function. To put the Lazy Function Definition in the game, you need to redeclare your function:

So the final code for the Lazy Function Definition Pattern looks like this:

What happens is:

  1. anchorChange5 gets called and defines the config variable and collects all the anchors on the page
  2. An onclick event gets attached to every anchor, with a call to the changeColor method of the redeclared anchorChange5 function
  3. After that, anchorChange5 gets redeclared and only holds the changeColor method, which can be accessed as a public method

And again, in the body of the page, you call the function:

There is, again, a working example with comments. As stated above, this pattern is not that handy here, but consider a situation when there is some heavy and complex computing involved. You certainly do not want to do that each time the function gets called. Peter calls this kind of function definition a “promise”, which means the outer declaration can be viewed as some kind of promise that later on this function will get redeclared to provide something more useful.

Appendix: Copy & Paste Example

The following code is an template/example you can copy & paste into your favourite editor and build up your module/feature from there. It is based on the Revealing Module Pattern and assumes you are using the Yahoo! User Interface Library (YUI). To get further filepaths of components to include for your module, visit Serving YUI Files from Yahoo! Servers.


As stated above, these are my assumptions on how this particularly simple task can be accomplished. I am sure that there are some other ways of approaching this problem, but my point in going through these exercises was to teach myself how these different methods work in general.

There is no general solution on how such problems should be approached. For a task like this, I believe that the singleton pattern is the most convenient way of doing it. Mostly because less lines of code are required. But for other, more complex problems, using the module pattern or creating custom objects or the lazy function definition might be more appropriate.

Further reading

Leave a Reply

Your email address will not be published. Required fields are marked *