JavaScript namespacing – an alternative to JavaScript inheritance

When talking about JavaScript and inheritance, something that often go amiss from the discussion is the alternative of using proper namespacing instead.


First, let’s establish that global variables are evil. Got that? Good. An alternative to that is to use an object to be the container for all functionality in a web site, e.g. the customer or product name. Let’s start with a simple example:

var Griffins = {};

I know, amazing, right? :-)

The idea here is that the empty Griffins object you have created will the super object to which everything else will belong. You can now add objects as part of that object, like this:

Griffins.Stewie = {
    evil : true,
    triesToKill : "Mom"


Griffins.Peter = {
    familyHead : true,
    responsible : false

Extending – not necessarily inheriting

As you can see from above, this technique allows you to to use just one global container, and then extend it with different objects and branches depending on desired functionality. The upside of it is that most objects become something like siblings to each other, rather than parent and child objects.

Compared to JavaScript inheritance

The reason I wanted to state that this might pose an alternative to JavaScript inheritance is that, in my experience, inheritance tends to be overused, and developers spend more time overriding functionality inherited from some sort of super object, instead of just focusing on the new object’s features. Basically, inheritance isn’t always the best way to go, whereas namespacing could be the best solution at hand instead.

Namespace assertion

Something to mention here is that if you have your code spread across multiple files, which seems very likely, to make sure the global object exists, you just need to add a little assertion to the top of each file using it, before you try to extend it:

if (typeof Griffins === "undefined") {
    Griffins = {};

Griffins.Lois = {
    strangelyHot : true,
    hasWeirdHusband : true

This code checks if Griffins is already defined, and if not, it creates a new namespace to add the Lois object to.

Reusage of methods across objects

Now you’re thinking that this approach results in a lot of redundant code, and being completely against DRY principles; on the contrary! The benefit is that from one object’s method, you can choose to just call the method of another, but within the right context. Let’s take a look at these two objects:

Griffins.Chris = {
    brainCapacity : "Low",
    getCapacity : function () {
        return this.brainCapacity;

Griffins.Meg = {
    brainCapacity : "Decent",
    lowSelfEsteem : "Low self esteem"
    getCapacity : function () {
        var capacity = Griffins.Chris.getCapacity.apply(this, arguments);
        capacity += " - " + this.lowSelfEsteem;
        return capacity;

// Returns "Low"

// Returns "Decent - Low self esteem"

What happens here is that the Griffins.Meg object reuses the getCapacity from the Griffins.Chris object, but calls it as itself, through the help of the apply method. I.e. the keyword this in the getCapacity for the Griffins.Chris object will then point to the Griffins.Meg object, getting the property brainCapacity from the correct object.

Evaluating options

So, what I wanted to say with this post is that JavaScript inheritance doesn’t have to be a bad thing, but that sometimes it’s just not the best way to approach a problem. Instead, good namespacing has proven to be very successful and a worthy alternative. Personally, I also think it’s very good for code clarity, instead of chasing up some prototype chains.

Posted in Developing,JavaScript,Technology |

Leave a Reply

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