Unobtrusive Java Script - A New Paradigm

A New Paradigm

JavaScript historically has had a reputation for being a clumsy, hackish language unsuitable for serious application development. This has been largely due to inconsistent implementations of the language itself and the Document Object Model in various browsers, and the widespread use of buggy copy-and-paste code. Runtime errors were so common (and so difficult to debug) that few programmers even tried to fix them, as long as the script behaved more or less the way it was supposed to; scripts often failed completely in some browsers.

The recent emergence of standards-compliant browsers, JavaScript frameworks and high-quality debugging tools have made organized, scalable JavaScript code possible, and the emergence of Ajax interfaces has made it desirable. Whereas JavaScript was once reserved for relatively simple and non-critical tasks such as form validation and decorative novelties, it is now being used to write large, complex codebases that are often part of a site's core functionality. Run time errors and unpredictable behavior are no longer minor annoyances; they are fatal flaws.

Advocates of unobtrusive JavaScript see it as part of the larger Web standards movement; much as the demand for cross-browser compatibility has driven the increasing emphasis on standardized markup and style, the increasing demand for rich Internet applications is driving the movement toward better practices with the use of JavaScript. The concept of unobtrusiveness in relation to JavaScript programming was coined in 2002 by Stuart Langridge in the article "Unobtrusive DHTML, and the power of unordered lists". In the article Langridge argues for a way to keep all JavaScript code, including event handlers, outside of the HTML. Stuart Langridge has since expanded upon this thought in book and article format.

Other authors have tried to refine and define the essential elements of the unobtrusive paradigm. David Flanagan's seminal JavaScript: The Definitive Guide says that while there is no specific formula, there are three main goals:

1. To separate JavaScript from HTML markup, as well as keeping modules of JavaScript independent of other modules.
2. Unobtrusive JavaScript should degrade gracefully - all content should be available without all or any of the JavaScript running successfully.
3. Unobtrusive JavaScript should not degrade the accessibility of the HTML, and ideally should improve it, whether the user has personal disabilities or are using an unusual, or unusually configured, browser.

The Web Standards Project describes four benefits of unobtrusive DOM scripting in their JavaScript Manifesto.

1. Usability: An unobtrusive DOM script does not draw the attention of the user - visitors use it without thinking about it.
2. Graceful degradation: Unobtrusive DOM scripts never generate error messages, in any browser, even when they fail. If features cannot be presented properly, they silently disappear.
3. Accessibility: If any script fails, the page still delivers its core functions and information via the markup, stylesheets and/or server-side scripting.
4. Separation: For the benefit of other and future web developers, all JavaScript code is maintained separately, without impacting other files of script, markup or code.

For the Paris Web Conference in 2007, Christian Heilmann identified seven rules of Unobtrusive JavaScript.

1. Do not make any assumptions: Defensive programming techniques should allow for the possibilities that JavaScript may not run, the browser may not support expected methods, the HTML may have changed, unexpected input devices may be in use and other scripts may either not be present or may be encroaching on the global namespace.
2. Find your hooks and relationships, such as IDs and other aspects of the expected HTML.
3. Leave traversing individual DOM objects to the experts, such as to the CSS handler built into the browser where possible.
4. Understand browsers and users, particularly how they fail, what assumptions they make, and unusual configurations or usages.
5. Understand events, including how they 'bubble' and the features of the Event object that is passed to most event handlers.
6. Play well with other scripts by avoiding global function and variable names.
7. Work for the next developer by using self-explanatory variable and function names, creating logical and readable code, making dependencies obvious, and commenting any code that still might confuse.