“JavaScript Wranglin’” or “How I learned To Stop Worrying and Love the DOM”


A short, abstract assessment of how one might improve performance, maintainability, and extensibility of the legacy JavaScript architecture on a high-traffic enterprise website; to create automated processes to perform continuous profile, test, build, integrate, and deployment work; to furnish a well-documented codebase to future developers.


First, make the JavaScript unobtrusive. This means separating the JavaScript from the HTML. All inline function calls must be removed from their respective elements and placed inside <script> blocks. If using jQuery, event handlers can be relocated to a $(document).ready block. Any JavaScript written inline should also be moved into separate (*.js) JavaScript files. When relying on dynamic, server-generated JavaScript, we might consider a solution like Node.js server that can create dynamic asynchronous JavaScript naturally.


Once this is done, we can start effectively using automation tools to improve the performance, maintainability, portability, and enhance-ability of the site’s JavaScript architecture. Among these utilities like JSLint, a JavaScript validation tool that can be customized to determine the compliance of a variety of different JavaScript coding standards (Douglas Crockford’s “Good Parts” being only one of many possible configurations).

In addition to this, it is helpful to trace variable declaration and instantiation; as well as calls to functions, their definitions, and the interdependency of the various <script> blocks and their data.


Part of this inventory process should involve narrowing the scope of our variable declarations. A cluttered global namespace (variable declarations in the root window object) leaves our data precariously vulnerable to unintended modification. And this risk only increases as the codebase grows in size and complexity. All of JavaScript should eventually be consolidated within the scope of a single short global root namespace, e.g. jQuery’s $ or the _ character in Underscore.js. Once the scope of our JavaScript is enclosed this way – and our code is starting to look more object-oriented – we can start looking at ways to logically organize functionality. This is where profiling can be more successfully leveraged for Big-O notation levels of scalability.


Beyond this we can look at our deployment process as having numerous facets, each with its own set of benefits. One example of this can be achieved once we have mapped out all of our variable declarations and file dependencies, we can use automated build tools for both unit- and integration-testing, as well as scheduled deployment of production-optimized JavaScript. These can be integrated into any cron jobs that might already be used for deployment. I’m still monkeying around with these, but both Maven and Ant can be used to automate build processes, integration testing, and production deployments.


JSDoc is a system of code comments that can be used to automatically create detailed visual documentation of an object model. It is extremely helpful in keeping track of how everything in your ecosystem is working.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.