Skip to main content

JavaScript Recomendations for AJAX Component Writers

Posted by gmurray71 on March 8, 2006 at 2:00 PM PST

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.

What would you add to the list?