Jumping Into Javascript – Namespaces, we should have more of these

The last article dealt with cross-domain data retrieval. This article will be a short discussion about namespaces and the module pattern in Javascript.

Here’s a snippet from the Zen of Python that I think should be included in some theoretical incantation of the Zen of Javascript:

Namespaces are one honking great idea — let’s do more of those!

Namespaces are an important concept in any programming language. Programming without them is inevitably an exercise in tracking down hard-to-find bugs that occur when a definition is clobbered by an unrelated assignment.

Here’s the problem: There is a single global namespace for all the scripts running in a page!

This means that defining: a = 42 in the file display.js will clobber the: a = 7 definition in database.js! Let me restate that. When you are creating global variables in a Javascript file, you must know about ALL the global variables created in ALL the other script files.

This may be possible for small apps that you write by yourself. However for large apps and/or when multiple programmers are working on the same project, this is a nightmare. Luckily there is a solution and it’s what I call the namespace pattern.

The namespace pattern is very similar to, but not quite the same as, the module pattern. The module pattern is designed to allow private/public attributes of an object, which has benefits and drawbacks that are outside the scope of this article.

Links that describe these patterns can be found at the bottom of this page. It is not within the scope of this series to describe all the aspects of the module pattern. I will, however, give a short overview of the two approaches that I think are worthy of consideration. The first is the module pattern and the second doesn’t have a name that I have found, so I’ll call it the Prototype Pattern.

Module Pattern

var MODULE = (function () {
  // all code here
  return {
    // return everything you want to be public

Prototype Pattern

var MODULE = {};
MODULE.variable = 42;
MODULE.fn = function (x) {return x*x};

With the module pattern you must declare everything you want to be public. With the prototype approach you must prefix every attribute creation/access with the namespace. I have read some articles that suggest that prototypes are more efficient than constructor functions. I simply don’t know enough about Javascript at the moment to make that claim. Please research this yourself if it is important to you, don’t take my word for it.

You may come across some “Module Pattern Considered Harmful” type articles when researching. To save you some time here’s the argument: the module pattern is not a solution for every conceivable problem, therefore it should be avoided. Some of these articles do raise valid use cases where the module pattern is not applicable, if you’re interested in that they are a good read. Just don’t drink the kool-aid and believe that they are always useless/harmful.

Most of the issues with the module pattern revolve around private attributes. I have spent most of my time programming in Python and Scheme and, in the general case, I haven’t had a need for private attributes. However the real benefit of the module pattern (IMHO) is not private attributes, but avoiding the global namespace problem. A problem for which the module pattern is an adequate solution.

GOTO Part 6 – Drawing JSONP Data on the Canvas

Get JamochaTrade on GitHub



JavaScript: The Good Parts
A Google Tech Talk given by Doug Crockford. This talk is a great overview of the good and the bad of Javascript for experienced programmers.

Javascript Programming Patterns
A good article that covers a number of methods of tackling the namespace problem.

JavaScript Module Pattern: In-Depth
More information about the module pattern.