JavaScript Programming Patterns

JavaScript is meant to be used to add behaviors to a website, might it be for form validation or for more
complex operations like drag & drop functionality or performing asynchronous requests to the web
server (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 Old-School Way

• Singleton
• Module Pattern
• Revealing Module Pattern
• Custom Objects
• Lazy Function Definition

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:

<ul>
<li><a href="http://news.bbc.co.uk/">News on BBC website</a></li>
<li><a href="http://nytimes.com/">Frontpage of The New York Times</a></li>
<li><a href="http://www.guardian.co.uk/">Guardian Unlimited</a></li>
</ul>

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:

function changeColor1(linkObj, newColor) {

linkObj.style.backgroundColor = newColor;
}

function anchorChange1() {
// set configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};

// get all links on page

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
changeColor1(this, this.color);
return false;
};
}
}

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:

<script type="text/javascript">
anchorChange1();
</script>

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:

function changeColor1() {
alert("oh noes, my code got overwritten!");
}

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.

Singleton
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:

var testObject = {};

For a start, I created an empty singleton:

anchorChange2 = {};

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:

config: {
colors: [ "#F63", "#CC0", "#CFF" ]
}

alterColor changes the background color to the new color:

alterColor: function (linkObj, newColor) {

linkObj.style.backgroundColor = newColor;
}

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

init: function () {
var self = this; // assign reference to current object to "self"

var anchors = document.getElementsByTagName("a");

var size = anchors.length;

for (var i = 0; i < size; i++) {

anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.alterColor(this, this.color); // this is bound to the anchor
object
return false;
};
}
}

The final singleton looks like this:

// singleton syntax
// creates a class and immediately instantiates an object
var anchorChange2 = {
config: {
colors: [ "#F63", "#CC0", "#CFF" ]
 },

// does the actual change of the background color

alterColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
},

init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {

anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.alterColor(this, this.color); // this is bound to the anchor
object
return false;
};
}
}
};

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):

anchorChange3 = function () {}();

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:

return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
alterColor(linkObj, newColor);
},

// public method
init: function () {
var self = this; // assign reference to current object to "self"
 // get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {

anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor
object
return false;
};
}
}
};

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

var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

function alterColor(linkObj, color) {

linkObj.style.backgroundColor = color;
}

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:

var anchorChange3 = function () {

// private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this is a private method

// can be accessed within anchorChange3
// cannot be accessed from outside
function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}

return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
// calls private function to change color
alterColor(linkObj, newColor);
},
 // public method
// can be accessed from outside
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {

anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the
anchor object
return false;
};
}
}
};
}();

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

<script type="text/javascript">
anchorChange3.init();
</script>

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:

var anchorChange4 = function () {}();

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

// this will be a private property

var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method

var init = function () {
var self = this; // assign reference to current object to "self"
 // get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {

anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor
object
return false;
};
}
}

// this will be a public method

var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

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:

return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}

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:

// revealing module pattern

var anchorChange4 = function () {

// this will be a private property

var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method

var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {

anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
 self.changeColor(this, this.color); // this is bound to the anchor
object
return false;
};
}
}

// this will be a public method

var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
}();

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

<script type="text/javascript">
anchorChange4.init();
</script>

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:

var anchorChanger = function () {};

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.

anchorChanger.prototype.config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

anchorChanger.prototype.changeColor = function (linkObj, newColor) {

linkObj.style.backgroundColor = newColor;
};

anchorChanger.prototype.init = function () {
 var self = this;

var anchors = document.getElementsByTagName("a");

var size = anchors.length;

for (var i = 0; i < size; i++) {

anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);
return false;
};
}
};

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:

// custom object constructor

var anchorChanger = function () {
this.init();
};

anchorChanger.prototype.config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

anchorChanger.prototype.changeColor = function (linkObj, newColor) {

linkObj.style.backgroundColor = newColor;
};

anchorChanger.prototype.init = function () {
var self = this;

// get all links on the page

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {

anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);
return false;
};
}
};

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

<script type="text/javascript">
new anchorChanger();
</script>

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:

var anchorChange5 = function () {};

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

// define configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};

// get all links

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
anchorChange5().changeColor(this, this.color);
return false;
};
}

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:

// redefine function so that it only holds the changeColor function

anchorChange5 = function () {
return {
changeColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
};
};

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

// lazy function definition

var anchorChange5 = function () {
// define configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};
 // get all links
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
anchorChange5().changeColor(this, this.color);
return false;
};
}

// redefine function so that it only holds the changeColor function

anchorChange5 = function () {
return {
changeColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
};
};
};

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:

<script type="text/javascript">
anchorChange5();
</script>

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).

<script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/yahoo-dom-

event/yahoo-dom-event.js"></script>
<script type="text/javascript">
// Creates a namespace for your Project
YAHOO.namespace("CRUSH");

// declare the module

YAHOO.CRUSH.someFunction = function () {
// set some configuation
var config = {};

var init = function () {

// set up the foundations
};

// private function
var anotherFuntion = function () {

};

return {
// set up which functions should be public
init: init
};
}();

// initialize the function

YAHOO.CRUSH.someFunction.init();
</script>

Conclusion

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.

Thanks for reading and checking out the examples. I would be very happy if you could provide me
with feedback.

Further reading

• A JavaScript Module Pattern: explaining how all this is applied at Yahoo!

• Christian Heilmann tells you how to Show love to the Module Pattern
• Lazy Function Definition Pattern by Peter Michaux
• Christian again, describing what he calls Revealing Module Pattern
• Richard Cornford on JavaScript Closures
• Douglas Crockford on Classical Inheritance in JavaScript
• Kevin Lindsey’s approach to simulating object-oriented programming in JavaScript
• Harry Fuecks from SitePoint on JavaScript inheritance