Namespacing Your JavaScript
There is just too much bad JavaScript in the world.
It’s sad because JavaScript, like other functional languages, has so much potential to be beautiful. One of the biggest contributing factors to nasty JavaScript is that it has an implied global scope. This was a originally designed to be a convenience to non-programmers who happen to find themselves programming JavaScript. As it would happen to be, the global namespace was one of the worst ideas Netscape ever had.
At the time of its design, JavaScript was simple and the applications that it produced were also simple. Things like mashups and other collaborative rich intenet applications were not even thought to be possible. So, with that mindset, it’s only natural to think that a loosely typed scripting language where everything gets dumped to the global object would be a good thing. Unfortunately, that mindset isn’t exactly forward-thinking.
We live in a world now where copy-and-paste applications are commonplace, JavaScript frameworks are everywhere you look, and those same non-programmers are somehow still hacking away. Meanwhile, in their code, seven concurrent for-loops are running, sharing the same i variable.
Sound bad? It is…
How to Make it Better
If JavaScript’s image is ever going to improve, people will need to start to take the language more seriously. For some reason, nobody seems to think about JavaScript programming in the same manor that they would another language. As Douglas Crockford puts it, “most people just fake it.” I’ll admit it, I was one of those people too. It was only when I began to take the language seriously, was when the quality of my code improved. Now that I have a greater understanding of the language, I have grown quite fond of it.
The JavaScript pros also need to start cleaning up their code too. You can throw a rock in any direction and hit at least five JavaScript frameworks. Take your pick at your favorite framework: Prototype/Script.aculo.us, MooTools, DoJo, whatever. They all boldly assume control over the global namespace.
Personally, I find that unacceptable.
I don’t think that it is too much to ask that the number of global variables be directly proportional to the number of libraries you have included into your application. Why can’t Prototype just build everything off of the already existing Prototype object? Why can’t DoJo do the same? YUI gets it. jQuery is close. Everyone else needs to follow their lead.
It’s Easier than You Think
Namespaces provide a simple way to define a container for all of your data. In JavaScript, you can put anything in a namespace: variables, functions, objects, whatever. It’s as simple as two curly braces.
var MIKEG = {};
MIKEG is an empty object. This is going to be my starting point for all code that I write in any JavaScript application. Lets say I want to add some convenience functions for working with XHTML and the DOM. They go right into my MIKEG object.
<br>// Create a HTML namespace to store HTML-relate functions.<br>MIKEG.html = {};<br><br>MIKEG.html.generateElement = function (sName, elParent, oAttributes) {<br> // Code...<br>};<br>MIKEG.html.applyAttributes = function (elTarget, oAttributes) {<br> // Code...<br>};<br>
It’s just that simple. I now have only one global variable in my entire application: MIKEG which provides me access to everything I need. My code is also well organized and easy to follow. Furthermore, if I continue with this discipline, I can code without fear that someone’s data will collide with mine.
The YUI provides a great utility to help programmers keep their code organized: YAHOO.namespace(). Just pass it the namespace you would like to create as an argument and you have your namespace registered within the YAHOO class.
For my development, I stick to my own MIKEG namespace which I keep external to any library. I do this because most of my code is library-independent and 100% portable. When I do implement YUI-specific code, I create a namespace using YUI’s namespace utility. Aside from the obvious visual clue that I’m using the YUI this insures that there will never be any possibility of my variables interacting with someone else’s.
The web is changing, JavaScript is becoming more popular, and the platform that JavaScript stands on is becoming more stable. It’s our duty as professionals to always remember to write clean, stable, and scalable code. Namespaces won’t solve all of JavaScripts problems, but it certainly helps make code more maintainable.
Comments are closed. Sorry.