This is the following article to part 1 on javascript patterns.

A namespace to rule them all

This is a small javascript framework that I use for starting my javascript/jQuery project. I think it could be most beneficial for those coming from libraries like jQuery. Dojo being quite expressive on how to work with it, and Mootools and Prototype being a bit more structured.

A small note, I used jQuery in the framework because of the AOP plugin (and because I mainly work with jQuery), you can erase any jQuery reference easily in less than 30 seconds .

What this framework aims to do:

  • Easy to understand
  • Modular
  • Each module will heritage a set of tools and each module can be instantiate
  • One namespace
  • Can apply tests or unit test out side of the application itself.
  • Use the jQuery aop plugin (aspect oriented programming) to add logs to internal functions

Download the source code

** I am not an expert in javascript design patterns, but that is what I have come to in light of my experience, I will certainly take constructive comments, and if you like it, please use and modify it as you want.


Download the full version in pdf

How it works

LABjs to load all your scripts
First thing first, in app.html you will see that JS files are loaded asynchronously from the bottom body tag with LABjs. This tools will make you js files load faster and your script will no longer block page resources download (images, etc). You can use .wait() to define load order if necessary. Have a look at the documentation. The major drawback from loading asynchronously is that you might have a situation where someone clicked on a button and the script associate with it might not be loaded.


I try to use only one or 2 namespaces for all my applications or even websites. This is why in objectUtils.construct.js you will see that the global namespace is define by this line:

/* Global App Namespace */ 
var ApplicationNamespace = {}

Each module will be declared using this object. So for example, a lightbox class would be declared this way : ApplicationNamespace.lightboxClass = function(){}


A typical module in your app should look likes this:

ApplicationNamespace.Classname = function() {
    // constructor    
    function privateFunctionInit() {
        // private
    this.privilegedFunction = function() {
        // privileged
ApplicationNamespace.Classname.prototype = {
    utils: object.create(namespace.moduleUtils),
    Method: function(){}
var class = new ApplicationNamespace.Classname();

We have a pretty cool module here. Let’s get a bit into details here.

This is a private function that will not be available in the global scope. These method cannot also be tested externally, unless doing a small trick that I will talk later on.

function privateFunctionInit() {
        // private

This is our privileged function that can access private functions and can be accessed outside after we instantiate it by using, in this case : class.privilegedFunction

 this.privilegedFunction = function() {
        // privileged

This will be called after we instanciate (var class = new namespace.Classname()) and automatically launch this init function. You should also note that this might happen before the DOM is ready, if you use jQuery you need the DOM ready wrapper here.


This is where we declare the prototype associate at our module and method shared by every instance of the module.You can have more informations on prototype in my other article.

ApplicationNamespace.Classname.prototype = {

This is where we get or create the utility module shared by every modules.

    utils: object.create(namespace.moduleUtils),

And finally we instantiate the module. There is probably a lot of modules that you might have to instantiate only one time.

    var class = new ApplicationNamespace.Classname();

Modules utilities object

The utility object is shared across every modules. the definition is done in objectUtils.construct.js.

This is notably important if you want to run some unit test or run some debug from outside your modules. One thing I really like to do,is using the jQuery AOP (Aspect oriented) plugin. This will allow you to bind debug methods to any functions in any modules, it also give you the DOM caller if it exist and it’s context. Here is an example:

moduleUtils.debug = {
	live : true,
	loadModal : function(){
		jQuery.aop.before( {target: appModal, method: 'load'}, function(object) { 
		    console.log('Modal opened'); 
	if( == true){

As you can see the object is created even if live is false (in production you might want to enable and disable it often), normally this file should not be loaded when the project goes live.

Unit Tests

I really wanted to include QUnit as a part of my work flow, unfortunately, you can’t load QUnit dynamically for now. I really want my unit tests to be in a small lightbox and decide to load it in my app from a small variable state. I will probably create a really small unit test plugin in the near future, I think this is really important to test regressions.

That’s it, here it is

I am certainly not going to say this is a perfect solution, but that’s what I use for now, it will certainly evolve with time.

Download the source code View demo

Version 0.5 Online

If you like and use this script, please consider buying me a beer, it’s cheap and a simple way to give back!