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.

Some nice stackoverflow discussions:

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:

var module= {
	init : function() {
	load : function() {
		/* instructions */
/* Load Init in your script */

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.

var revealingModulePattern = function(){
  var privateVar = 1;
  function privateFunction(){
  var publicVar = 2;
  function publicFunction(){
  function anotherPublicFunction(){
  // reveal all things private by assigning public pointers
  return {

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:

var namespace = {};
namespace.Classname = function() {
    // constructor    
    function privateFunctionInit() {
        // private
    this.privilegedFunction = function() {
        // privileged
namespace.Classname.prototype.aMethod =function() {
namespace.Classname.prototype.anotherMethod = function() {}
var class = new namespace.Classname();

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.

10 thoughts on “Javascript patterns headache, the path to modular applications (part 1)

  1. Nice post. I see some js libs like SWFObject use the module pattern. I often use this one and love this too. The big benefit of this method is allowing us to create private functions and private variables.

  2. . I was extremely pleased to find this website.I wanted to thank you for this good understand I definitely enjoying every single small bit of it and We’ve you bookmarked to check out new stuff you post.

  3. Javascript patterns headache, the path to modular applications (part 1) Position Absolute Pretty nice post. I just stumbled upon your weblog and wished to say that I have really enjoyed surfing around your blog posts. In any case I will be subscribing to your rss feed and I hope you write again very soon!

Comments are closed.