Wed, Jul 27, 2005

Best Practices: Implementing javascript for rich internet applications

by Austin Govella

While Ajax and rich interfaces have fueled inspired innovations, the all the excitement threatens to forget best practices for using javascript.

Comments

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

Separate content from presentation and behavior

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.

Talk About "Best Practices: Implementing javascript for rich internet applications"

DOM Scripting Task Force » Blog Archive » Best practices said:

[...] 7th, 2005 by Jeremy Keith Austin Govella put together a nice little round up of best practices for using JavaScript: Separate Behavior from Content and Presentation Provide progress [...]

Wed, Jul 27, 2005

JD on MX said:

Links from the desktop Links from the desktop: I've got lots of browser windows open, and want to get some of these links into the weblog's database, but I don't want to flood the aggregators… if you've got some time to poke around here,…

Wed, Jul 27, 2005

Jonathan Boutelle's home on the net said:

Best Practices for AJAX development It's great to see developers starting to think seriously about what kind of best practices to use in javascript development. Developing with a loosy-goosy scripting language like JavaScript or ActionScript requires MORE code discipline, not less. Since the language doesn't…

Thu, Jul 28, 2005

newsight said:

Best Practices for AJAX development Which points you should consider on the development of AJAX applications, are described in this article.
[via JonathanBoutelle.com]

…

Thu, Jul 28, 2005

CFUG Nord said:

Beste Methoden f?ɬ

Thu, Jul 28, 2005

newsight » Blog Archive » Best Practices for AJAX development said:

[...] Which points you should consider on the development of AJAX applications, are described in this articl [...]

Thu, Jul 28, 2005

basimo.de said:

JavaScript richtig einsetzen Auf Thinking and Making gibt es ein paar grundlegende Tipps, wie man JavaScript in Web-Applikationen verwenden sollte: Trennung des Verhaltens (JavaScript) von Inhalt (XHTML/XML) und Pr?ɬ

Thu, Jul 28, 2005

AJAX said:

Best Practices: Implementing javascript for rich internet applications Thinking and Making blog have a nice post about best practices for AJAX development.
Five simple, best practices help ensure a project implements javascript in the most effective an

Thu, Jul 28, 2005

Surf 11 said:

AJAX Best Practices

Thu, Jul 28, 2005

Sean Hogan said:

No arguments with the practice outlined here… good advice for holding down complexity while adding functionality.

I think there are two reasons for scripting.

1. Generic behaviors which effectively create a new element from one (or several) current ones. These behaviors make sense in many contexts, and will get bundled into tomorrow's standards (or are used to bring old browsers up to scratch). Think all the UI elements you have to script for HTML (and are already in Mozilla XUL) - decks, tabboxes, listboxes, menus. Also Dean Edwards fixes for IE.
These behaviors are generally attached by className or type.

2. Page-specific behaviors which only make sense for one page or page-template. Think broadcasters and observers in Mozilla XUL. They are very simple because they make use of generic behaviors to do any significant work.
These behaviors are attached by id.
It also doesn't matter so much if specific behaviors are inline or separate.

Sat, Jul 30, 2005

Austin Govella said:

I didn't know decks, tabboxes, etc. were in Mozilla XUL. I've been looking at Backbase who have a nice tag oriented method for creating them.

I agree with your distinction between the two types. I think it kind of follows the idea of progressive enhancement versus totally new interfaces.

Sat, Jul 30, 2005

Chan Xie said:

Could you explain how IE internally handles CSS?

Is there a function/method that I can call to show the actual code of the "Presentation (CSS/XSLT)" stage, like document.documentElement.outerHTML for the "Content (XHTML/XML)" stage?

Thanks,
Chan.

Mon, Aug 1, 2005

Austin Govella said:

Chan Xie:

On the webdesign list Massimo Foti suggested using Mozilla's DOM inspector.

Web Design List: http://webdesign-l.com

Tue, Aug 2, 2005

.complex » Blog Archive » My last random “keep these in the back of your head” links for the day, promise. said:

[...] he back of your head” links for the day, promise. August 5th, 2005 Best Practices: Implementing javascript for rich internet applications Best Practices for AJAX Developme [...]

Fri, Aug 5, 2005

Worm in liquid maze said:

Turns of liquid maze I have planned originally to publish links to interesting articles and websites on daily basis….

Fri, Aug 12, 2005

Kent Brewster said:

This is a very cogent wrap-up of many issues facing 21st-century user experience engineers, Austin. Very nice, thank you!

Some quibbles: I'm not sure I agree with the caption under your diagram. I tend to think in terms of structure, presentation, and interaction, not content, presentation, and behavior.

The presentation layer (hiding a division, for instance) acts on structure, not content; that content is either already on the page or waiting on the server for a cue from the interaction layer. I try to stay as far away from "content" as I possibly can. Where I work, the only people who touch content are producers.

Fri, Aug 26, 2005

Austin Govella said:

Kent, I agree with your breakdown: structure and interaction in place of content and behavior. I was trying to use more common terms, even though they can be less accurate.

I will say that I think using "interaction" here muddles things. Interaction is what happend in the space between the user and the structure/presentation.

"Behavior" describes what happens on the user's side the same way we describe what's happening on the "page" side. Neither side is priveleged, which is an important facet for me: in my interaction diagrams, there's no at face distinction between people and machines.

Fri, Sep 9, 2005

Code and Whatnot » Blog Archive » “No More DotProject,” and “Where Have I Been?” said:

[...] em is that it tries to do too much, and ends up with a really obtuse interface. With AJAX maturing, I see great things ahead for open-source, web-based enterprise software. In the case of projec [...]

Fri, Sep 23, 2005

Shawn Brown said:

Regarding a separate behavior layer:

Earlier this year I switched to a templating system that uses XHTML Basic for its content files. Since XHTML Basic doesn't support inline event handlers, doing this enforces clean behaviour-layer separation.

To attach events, I've been working on a reusable method that mimics CSS (EventX: Cascading Event Extensions).

I settled on this method after finding the W3C's defunct BECSS working draft and Netscape's old Action Sheets submission. I haven't seen much mention of these papers in layer-separation articles though.

Thu, Oct 13, 2005

Thinking and Making said:

[...] Name('a'); for (var i=0; i Users ignore error messages 3 Best Practices: Implementing javascript for rich internet applicati [...]

Thu, Nov 3, 2005

Ioan Vlad said:

Wow. This is the first good explanation of separation between behavior and presentation I encounter. Now I understand why deprecation of target attribute of a link in XHTML is not a cruel joke, but actually a clean thing. One elegant aspect of this separation that could be mentioned in the article is that it allows easy switching to other client-side scripting solutions than javascript. Right now there are none really and I personally see nothing wrong with javascript, but who knows what will be 10 years from now. Going into HTML files to convert inline scripts would not be very fun, but external scripts can be easily changed.

Sun, Jan 22, 2006

Austin Govella said:

Ioan,

Your absolutely right about switching client-side scripting solutions. You can also switch presentation layer solutions, too. And not just for a CSS alternative.

It's not taht hard to serve the same content with different presentation and behavior layers targeted for different devices.

Thu, Jan 26, 2006

Wijiqod said:

Cool site man. Hi, firstly I'd like to say your site is great and very impressive.

Thu, Mar 9, 2006

Best Practices - The Web Standards Project said:

[...] Skip to comment form


Austin Govella put together a nice little round up of best practices for using JavaScript: Separate Behavior from Content and Presentation Provide progressive [...]

Wed, May 10, 2006

Chad’s dailies » Blog Archive » links for 2007-03-25 said:

[...] Implementing javascript for rich internet applications (tags: javascript bestpractices) [...]

Sun, Mar 25, 2007

Subscribe to the feed.