Namespacing your JavaScript
Perhaps a very uncommon approach to developing web applications that require JavaScript (but should be more common) is namespacing your scripts. This can be done very simple-like in a manner that is painless and nice-looking. And I know "looking-nice" should generally not be a determining factor on how your code should be written, but this indeed has some benefits as well.
Coming up with a Name
First things first, we need a name to space. If I were me (sometimes I'm not), but if I were, I would go with my own name Dustin Diaz
. But of course, I'd want to abbreviate that to just DD. However since I don't want this to be confused with Drag n' Drop,
I'll add my middle initial which will make it DED. Now from this point on, all JavaScript for DustinDiaz.com or developed by me for others, it will live under the DED Object.
Extending the namespace
Perhaps my most favorite way of setting up an application object is to do the following steps:
- Create the
DEDObject as a function literal - self-invoke the function
- return my methods
This is demonstrated below:
Namespace Object example
var DED = function() {
return {
method_1 : function() {
// do stuff here
},
method_2 : function() {
// do stuff here
}
};
}();
The benefit of this structure is that due to the fact that we have a function literal, we can add private properties and methods into the function before returning an object. This can be done as follows:
adding private properties and methods
var DED = function() {
var private_var;
function private_method() {
// do stuff here
}
return {
method_1 : function() {
// do stuff here
},
method_2 : function() {
// do stuff here
}
};
}();
In this case if we were to set our private_method to return... oh I dunno, "Hello World" - then we can call that within our public methods, alert it, and indeed receive a nice little message. However one thing to note, I would argue whether or not our public methods are... public. Of course, in this simple example, they are nothing but public. But there are also "privledged methods" which have access from the outside (public) and also have access to private methods. They are indeed possible to delete and replace, but you can never get at the information to which they were trying to keep secret.
Douglas Crockford also explains a bit on this in relation to Objects and its members, and specifically using the this keyword in his article labeled private memebers in JavaScript. Hopefully the examples on this page will get you thinking of how better to organize your code, avoid conflicts with external application code, playing nice with the "other JavaScript kids," and indeed the benefits of closures (inner functions). Have fun!
recent
- Matador: The Obvious MVC Framework for Node
- Sandboxing JavaScript
- Crouching Ender, hidden command
- Ender.js - The open submodule library
- Qwery - The Tiny Selector Engine
- Klass
- Smallest DOMReady code, ever.
- $script.js - Another JavaScript loader
- About that slowness on Twitter...
- Autocomplete Fuzzy Matching
- JavaScript Cache Provider
- JavaScript Animate
- Asynchronous method queue chaining in JavaScript
- Something changed
- Unofficial Twitter Widget Documentation
i am dustin diaz

