As I develop more applications that leverage JavaScript–both for data manipulation AND for superfluous effects–the more I come to realize the inexpressible need for finding as many shortcuts as possible. Without exception, as my JavaScript becomes more involved, so the complexity increases exponentially. To remedy this, I've started relying on frameworks such as Adobe's Spry, mooTools, jQuery, etc. to make my life easier for everything from element selection to major effects processing.

However, probably the biggest time-saver is making a concerted effort to make my JavaScript unobtrusive. What is this, you say? Well, by no means does it have a solidified meaning. However, a few principles are core to any definition.

The first is the idea of abstracting the functionality of JavaScript (be it data handling or effect processing) from the design layer on which the functionality is placed. In short, this means that the HTML markup of a site (and its corresponding CSS) should not be dependent on the functionality of JavaScript; rather, the functionality of JavaScript should be "pluggable" into the markup that it finds.

Now of course, this is all-too-idealistic. There is never a scenario in which markup and functionality are mutually ambivalent towards one another. However, the premise is still sound. Even as style (CSS) and markup (HTML) should live cohesively, yet independantly, so should JavaScript and HTML.

This means, then, the end of inline JavaScript function calls. No more "<img src='foo.jpg' onclick='doFoo()' />'. The answer? Register an event-listener that will perform the exact same functionality, but will additionally not be render-glued to the HTML to which the action is applied.

Now believe me, I've only been doing this for just a few months and I've quickly found that registering event-listeners and all the other fun unobtrusive novelties of JavaScript IS A LOT OF WORK! It's simple to slap down some inline function calls, but requires more thought when registering event listeners. Plus, you have to think about the implications of 'bubbling', the possibility of a need to remove these event-listeners, etc.

At first glance, it does not seem worth it. More complex code, more work. Hmm, maybe I'll pass. But wait! There are HUGE benefits.

The first (and most important in my mind) is that inevitably, unobtrusive JavaScript SAVES time. Even though it takes more time initially to setup, the long-term benefits to an application are innumerable.

Consider a scenario where you have a very simple, routine function that has inline processing on, say, 15 pages. What happens if you need/want to change the name of that function, or any arguments that might be passed in it? Well, you're screwed. You'll have to run through 15 pages, making sure to make the correct modifications to the appropriate peices.

With unobtrusive JavaScript, however, this problem disappears completely. As long as the markup remains the same across those pages, a change to a function that affects those 15 HTML elements is as simple as a single change to a single file that manages the event-listeners for those elements. Just stopping there, the argument for unobtrusive JavaScript is won.

However, it gets better.

Some JavaScript libraries use *funky*, non-standards-compliant special tags for their inline processing. While the JavaScript works brilliantly, W3C will pitch a fit about the non-compliant code that has been generated. So why are these tags created in the first place? Well, they are simple ways for the JavaScript framework to find its special elements and apply the necessary processing to them. But with unobtrusive JavaScript, these non-compliant tags are rendered completely unnecessary. Because elements and events are being defined in abstraction from the markup, there is no need to identify inline areas for processing. These elements have already been identified independantly of the markup, and can therefore be processed for the JavaScript framework as if nothing has changed.

Without question, my brief description of the benefits of unobtrusive JavaScript hardly does justice to the promise that it holds for seriously robust development, and I have not even mentioned the way in which it aids the development of accessible content. Nonetheless, I am very excited about what can be done with it, and hope that this is an inspriing discussion to other designers who are looking for better and more efficient ways to create richer experiences on the web.