Javascript patterns headache, the path to modular applications (part 1)

With libraries like jQuery, manipulating the DOM, ajax calls, animating has become really trivial. The problem is, it also becomes easy to have a mess of DOM ready statements without any comments or structure.

One thing most javascript developers start to do at some point is use objects literal to structure their code. This is a start, but currently creating a front-end intensive web app, I started to wonder if I could do better.

My goal was:

• Easy to understand
• Modular
• Each module will inherit a set of tools and can be instantiated
• One namespace
• Can apply tests or unit test from outside of the application.
• Can use the aop plugin (aspect oriented programming) to add logs to internal functions

First, I would suggest you look at a couple of resources if you are not too familiar with javascript patterns.

• Alex Saxton on javascript and jQuery pattern
• Using Objects to Organize Your Code – Rebecca Murphey
• Javascript: The Good Parts (Chapter 5) (book) -Douglas Crockford
• Prototypal Inheritance in Javascript -Douglas Crockford
• The secrets of the Javascript Ninja -John Resig
• Pro Javascript design patterns – By Ross Harmes, Dustin Diaz

Some nice stackoverflow discussions:

• Are design patterns in JavaScript helpful? And what exactly are they?
• What Are Some Examples of Design Pattern Implementations Using JavaScript?
• What JavaScript patterns do you use most?

With this in mind, 3 patterns sticked more than the others, let’s check them all.

** I am not an expert at javascript patterns and inheritance but I think it was nice to share my findings, please feel free to discuss and correct this article in the comments if necessary.

Object Literals

Object literals are great. You get a pattern that is simple and easy to organize, everything is public, everything can be overwritten, so you don’t have to worry too much about having things you can’t access. Easy to follow and understand, even for new comers.

A typical object literal:

The “self executing” revealing module pattern

The module pattern is a little bit more complex than a simple object literal, that being said, it gives you more power over what you want to be private and public. Basically you hide all your module behind a closure, this closure makes everything in the function private. You then use return {} to make a reference to a function you want public.

Now I will not get in the private or not debate, but I will say that some people disagree with this pattern.

As you can see, you create a public reference to the private function. That was my main problem with it. You never really have access to the public function, you just use a bridge to fire it. It creates problems when you want to bind something to a public function, it will never fire if this function is fired internally. Also, You can’t modify this object.

The module pattern, prototype style

Ahh prototype, those damn prototypes. I found this pattern gave me more liberty, and at the same time, a way to really use my public functions and not just reference them. On the question, but what is a prototype? Let’s just put it this way without going into details:

In the example below, namespace.Classname.prototype will be referenced by every instance you create with “new namespace.Classname();”. So a prototype would normally exist 1 time, if you would create 2 instances, and add a new prototype method, both instances would see it. In brief, when you create a new instance, everything in “namespace.Classname = function() {” is cloned, everything in “namespace.Classname.prototype” is not cloned, and is shared with all instances.

Here what it looks like:

Now this is really not what Crockford would advocate, but still, I found this was the pattern that was suiting best my ‘global’ needs.

Hope this helps you in your quest of modular javascript . In part 2, I explain my javascript “framework”, this is really just my starting point for creating apps, or even just a website.