Organizational standards are wonderful things.  They enforce consistency, help insure institutional competence and can dramatically reduce the learning curve to get additional staff up to speed on a project.  At the same time, in the world of AJAX standards can be too slow to adapt to a constantly changing landscape.  How do you strike a balance between flexibility and consistency?

 Project Specific Framework Selection

This is one of the most common approaches and is definitely the most flexible.  Project specific standards basically let the needs of a given project describe the choice of frameworks.  A project needing lots of animation and color manipulation may be built using mootools, a complex RIA may be built using dojo & a simpler project may use prototype or jQuery.  The problem with this approach is the frequent need to learn new API’s & potential to develop overly superficial knowledge of toolkits that may lead to unnecessarily cumbersome solutions.

Selection of Approved Frameworks

A step beyond project specific framework selection is the adoption of 2 – 4 approved frameworks within an organization.  In this arrangement, you try to achieve a balance between project appropriateness and standardization.  Usually the frameworks are chosen to accommodate different scales of projects.  A natural breakdown is the use of prototype & scriptaculous where scriptaculous may not be used in every project.  Another breakdown may combine a simple framework like prototype with a RIA platform like Dojo & an intermediate toolkit like jQuery.  In any event, it’s usually a good idea to pick platforms with similar coding styles & api’s to maximize the transference of skills between projects.

Standardizing on a Single Framework

This is definitely a popular approach and prevents any problems with developers needing to relearn things to get up to speed on different projects. Unfortunately, it’s a very high risk approach as toolkits frequently aren’t optimal for every project (e.g. dojo for a brochureware site and prototype for a webmail client).  There’s also the unfortunate possibility of a framework transitioning to an inappropriate licensing model or being abandoned as well.

Standardized Coding Practices

This is a strategy that can be adopted independent of your framework strategy.  basically, since so many of the various frameworks share constructs and they are all based on javascript.   Adopting a set of coding standards can dramatically simplify collaborative development.  Some of the strategies to consider are:

• Standardized Naming Conventions (camelcase, underscore etc.)
• Standardized File Names
• Standardized Function Names
• Comment Formating
• Chaining limits

We’ll discus coding standards more in the future, but since I’ve had several recent discussions on adopting a standard for my organization.  I thought I’d share some of our thoughts with you.

• Great Article on Ajax Interface Construction & Best Practices
• Roll Your Own JS Framework: Is It Necessary?
• Javascript Menus: The Good, The Bad & The Superfluous
• Excellent Resource for Learning MooTools
• Cross Site Scripting – the new old way
• Using the jQuery data method as a local datastore
• Javascript Testing with Test from Javascript MVC
• DamnIT Remote Javscript Error Reporting
• Implicit Vs. Explicit Conversion in Javascript
• Javascript Best Practices: parseInt( x, 10 );