Best Practices: Implementing javascript for rich internet applications

Published Wed, Jul 27, 2005 by Austin Govella. Updated Wed, Jul 27, 2005.

Recent interest in rich, asynchronous, web applications drove many designers and developers to quickly implement javascript widgets to a wide variety of web applications. While the excitement has fueled inspired innovations, the race has left behind several emerging best practices for using javascript.

Adding best practices to an application’s technical requirements speeds development, decreases the application’s total cost of ownership, and makes application code more easily reusable — which allows value created by the code to spread across an entire organization (instead of chaining value to a specific project).

Five simple, best practices help ensure a project implements javascript in the most effective and valuable way.

Separate Behavior from Content and Presentation

Diagram showing separation of content, behavior, and presentation

Just as we separate Presentation (CSS/XSLT) from Content (XHTML/XML), we should also separate Behavior (Javascript). This is called unobtrusive Javascript. Just as we link to external CSS files, we should link to external javascript files.

Instead of hard coding behavior into the content (e.g. onmouseover, onclick, etc.), behavior should be dynamically added to elements, classes, and unique elements (IDs) using the DOM. The foundational document, the content, should contain only valid XHTML/XML and no javascript.

Provide progressive enhancement

Javascript should augment content by adding behavior. The content should remain useful and usable without javascript (or without full javascript support). Even web applications intended to allow users to manipulate data should deliver content in its initial state. Javascript should allow users to change the content. It should not bar them from the content.

Code for flexibility

To make behavior most flexible, allow developers to choose whether or not the javascript will be triggered by elements, classes, or specific elements (ids). Additionally, publicly available javascript often requires specific classes, elements, or ids to work. Allow developers to specify the element, class or id that will trigger the behavior by setting these as variables at the top of the script. Enabling developers to specify the names for triggers, allows them to create markup with meaningful, semantic structure.

Alter content as little as possible

If a behavior changes only the presentation of the content, then it is preferable to change the targeted element’s class or id and allow CSS/XSLT to manage the change in presentation. If the behavior changes the content, javascript should output valid XHTML/XML that is as simple as possible (but no simpler).

Document output, parameters, and dependencies

If the behavior changes an elements class or id, document this in the script. Likewise, if the behavior changes the content or outputs additional content, document what the output will look like.

Along the same lines, javascript libraries often bundle together numerous functions that control a wide variety of behavior. For each function, document any library dependencies. Knowing library dependencies allows developers to remove portions of the library they won’t be using and optimize their application. Alternatively, one could design the library to only include the necessary functions (e.g. Dojo).

Open source and in-house javascript development

Open source development very obviously benefits from applying these best practices. By creating flexible, customizable, and reusable code, open source initiatives increase the likelihood their projects will be widely adopted.

In-house developers may incorrectly argue that since wide adoption and reuse are not factors, flexible, reusable code is a non-issue. However, these practices are in line with commonly accepted best practices in programming and keep javascript development in line with the D.R.Y. principle and help make sure code maintains a minimum level of object orientation.

Regardless of the code’s expected final destination, flexible, customizable, reusable code adds more value to the parent organization’s total equity without adding any appreciable cost to development, and these best practices should be added to the technical requirements of any project that will implement javascript.