JavaScript Recomendations for AJAX Component Writers

With AJAX there are many choices on how to use different aspects of JavaScript. Here are some recommendations we came up with for using JavaScript with the focus on creating AJAX components that will interact with a Java technology based server. Each of these recommendations is linked to a larger document that contains more details and in many cases code samples.
* Use JavaScript Programming Conventions
Standardize style makes code easy to work with and maintain especially in larger organizations. See the of JavaScript Programming Conventions created by the Dojo folks.
* Use object oriented JavaScript
Writing object orient JavaScript will allow for code re-use, enables you or others to extend your objects, and allows your scripts to be loaded and initialized dynamically.
* Use object hierarchies to organize JavaScript objects
When writing components use objects and object hierarchies to organize related objects and prevent naming collision.
* Use the prototype property to define shared behavior and to extend objects
Use the prototype property to extend, add functionality, or provide defaults to your objects. Use the prototype property to define shared functions (behavior) across instances of an object as it will reduce the number of objects in JavaScript and its use provides a good separation of behavior from data.
* Store state specific to the view in JavaScript and state that span pages on the server
Store view state related to a specific page using JavaScript objects. Keep in mind that JavaScript objects are specific to a HTML page and will be lost if the "Reload" button is pressed, if the browser is relaunched/crashes, or if you navigate to another page. Store state that spans pages on the server as Java objects scoped to the HttpSession. The client and server objects should be synched on page refreshes and page loads.
* Write reusable JavaScript
JavaScript should not be tied to a specific component unless absolutely necessary. Consider parameterizing data in your functions instead of hard coding the data.
* Use object literals as flexible function parameters
Object literals are very handy in that they can be used as generic for passing in arguments to a function. Since the function signature does not change if you choose to require more properties in a function, consider using an object literal as the parameter for a function.
* Compress your JavaScript
Not to be confused with a zip compression scheme compression refers to removing the white spaces and shortening the names of variables and functions in a file. Consider compressing your JavaScript resources when you deploy your application.
* Do not compress your Jar files that contain your scripts
Do not use zip compression on jar files with scripts or styles that are served by a server side component. Compressing those jars will cause the server to decompress the file for each client request for the script or resource. Larger scripts could cause performance problems for your server.
* Protect your server side assets
Never put business logic or server-side access code in JavaScript. Always validate request parameters on the server regardless of whether the request originated from an AJAX client or not.
* Consider loading JavaScript on demand
JavaScript may be loaded dynamically at runtime using a library such as JSAN or done manually by using AJAX to load JavaScript code and calling eval() on the JavaScript. This is useful if you have a large library or set of libraries.
* Consider using JSON for model data transport
While the XML is still a valid format for model data transport in AJAX (especially in cases where you're communicating with XML based services or your services must also address non-AJAX based clients), you should consider using JSON to communicate data from your server to your JavaScript based client.
* Provide a clean separation of content, CSS, and JavaScript
A rich web application user interface is made up of content (HTML/XHTML), styles (CSS), and JavaScript. JavaScript is invoked by user gestures such as mouse clicks and can manipulate the content. Separating the CSS styles from the JavaScript is a practice which will make your code more manageable, easier to read, and easier to customize. It is recommended that the CSS and JavaScript are placed in separate files.
* Avoid static content in JavaScript
Keep the amount of static HTML/XHTML content in JavaScript to a minimum. This will make managing the source and updating static content easier. You may want the content in your components updateable without changing your source.
* Use caution with element.innerHTML
If you choose to use element.innerHTML try to write JavaScript that generates minimal HTML. Rely instead on CSS for enhancing the presentation. Remember to always strive to separate content from presentation. Make sure to de-register event listeners in the existing innerHTML of the element before re-setting the element.innerHTML as it will lead to memory leaks. Keep in mind that instances of DOM elements inside the element.innerHTML are lost when you replace the content and references to those elements will be lost as well.
* De-reference unused objects
Make sure you de-reference variables when they are no longer needed so they may be garbage collected. If you are using element.innerHTML, make sure you de-reference any listeners in the code before it is replaced.
* Use care with closures
If you use closures take caution not to hold on to references to browser objects such as DOM related objects using the local variables of a closure as this can lead to memory leak. Objects are not garbage collected until all references to objects are gone. Make sure you understand closures in order to avoid creating them accidentally.
* Enable resource overrides in your components
Provide a means to override the loading of resources such as dependent scripts, CSS files, or images by your JavaScript centric, JSP, Servlets, or JSF components. If you jar your component for distribution with a JSP tag or JSF component, move those resource files into the WEB-INF directory and create code to stream them out to the client. This will allow your customers to customize the component styles or JavaScript on a case by case basis without rebuilding and re-packaging the component.
* Design with I18n in mind
Internationalization should not be an after thought. From the JavaScript client's perspective you need to do two things: Set the page encoding and make sure localized text is passed back to your server backend. Consider using XML as the return content type for localized data as XML can specify encoding information that is understood and applied by the XMLHttpRequest object. If you are passing around localized content you need to make sure you server encodes the return content properly.