In a project I am working on I am structuring my code as follows

MyLib = {
    AField:0,

    ASubNamespace:{
        AnotherField:"value",

        AClass:function(param) {
            this.classField = param;

            this.classFunction = function(){
                // stuff
            }
        }
    },

    AnotherClass:function(param) {
        this.classField = param;

        this.classFunction = function(){
            // stuff
        }
    }
}

and so on like that to do stuff like:

var anInstance = new MyLib.ASubNamespace.AClass("A parameter.");

Is this the right way to go about achieving namespacing? Are there performance hits, and if so, how drastic? Do performance degradations stack as I nest deeper? Are there any other issues I should be aware of when using this structure?

I care about every little bit of performance because it's a library for realtime graphics, so I'm taking any overhead very seriously.

In a project I am working on I am structuring my code as follows

MyLib = {
    AField:0,

    ASubNamespace:{
        AnotherField:"value",

        AClass:function(param) {
            this.classField = param;

            this.classFunction = function(){
                // stuff
            }
        }
    },

    AnotherClass:function(param) {
        this.classField = param;

        this.classFunction = function(){
            // stuff
        }
    }
}

and so on like that to do stuff like:

var anInstance = new MyLib.ASubNamespace.AClass("A parameter.");

Is this the right way to go about achieving namespacing? Are there performance hits, and if so, how drastic? Do performance degradations stack as I nest deeper? Are there any other issues I should be aware of when using this structure?

I care about every little bit of performance because it's a library for realtime graphics, so I'm taking any overhead very seriously.

• javascript
• namespaces
• structure

• 1 Essential JS Design Patterns Book contains a chapter about namespace patterns. – hellectronic Commented Aug 16, 2012 at 10:09

3 Answers 3

I suggest namespacing is a critical part of writing maintainable JavaScript - especially if you work with a team of developers.

Performance issues related to namespacing should be minimal if you press/minimize your code on the way to production.

Here is an SO discussion of alternative ways to use namespaces.

When you structure your code as a big giant object-property hierarchy, you sometimes have issues where MyNamespaceObj.prop1 isn't available to MyNamespaceObj.prop2 yet. And then there's the fact that you often end up typing fully qualified names a lot throughout the code.

I'm starting to find I prefer doing something like this:

MyNamespaceObj = (function () {

    // lots of code/definitions that have local scope
    var internallyDefinedItem1 = function (n) { /* ... */ }
    var internallyDefinedItem2 = {
        foo: internallyDefinedItem1(532),
        bar: totallyPrivateNeverExportedFunction(17)
    }
    var totallyPrivateNeverExportedVar = 'blahblahblah';
    function totallyPrivateNeverExportedFunction (x) {
       /* ... */
    }

    return {
        exportedItem1: internallyDefinedItem1,
        exportedItem2: internallyDefinedItem2,
        ...
    }
})();

Namespacing your JavaScript is critical to avoid potential conflicts and overwrites. This is specially true when your JS will land up in foreign environments where external JS can also reside.

With that said, there is a performance hit because of namespacing, simply because the interpreter now has to follow a longer chain to access the required function/property.

For example, something like

  var myProperty;

is accessed a little faster as pared to :

 myNameSpace.module1.myProperty;

I think the difference in speed is not much unless you namespace extremely deeply and the advantage of avoiding potential conflicts is a big plus of namespacing.

But still, it is always good to keep this issue in mind.