Know When Not to Use AJAX
AJAX is cool and glitzy, but there's nothing worse than a Web site that is all bling and no substance. Ideally, your users shouldn't even know there's "AJAX" on the page. They should simply feel that your Web application is responsive and enjoyable to use. In fact, if at any point they look at the screen and say, "There's some of that AJAX stuff," you've gone too far. For example, stay away from using drag-and-drop just because it's cool and stick with time-tested user interaction styles. Also, use client-side JavaScript when it makes sense and avoid server roundtrips if they don't add value.

Use Just Enough Tools
With AJAX, developers need not overextend themselves. There's no reason to use a giant framework. Staying lean helps avoid vendor lock-in, reduce the learning curve, and makes it easier to debug and grow quickly. Firebug, the Firefox plug-in, is the developer's best friend. It's outstanding for JavaScript, AJAX, and CSS and can incorporate the add-on YSlow, which profiles a page, suggests areas to improve, and helps you optimize pages only after everything works. Be sure to log important events to files, preferably a single file, so you can quickly debug and run down small issues before they turn into big ones. Simple processes and tools like these make developers more agile, as they take less brain space to learn and modify over time. It may be counterproductive to use a gigantic proprietary IDE with dozens of plug-ins and component libraries to do modern Web development.

Use Open Source
Since AJAX isn't specifically tied to any projects, open source solutions are probably the best route to take. Open source provides a plethora of options, always at the fingertips of any software developer. And with others constantly working with and refining open source software, it only gets better. Some packages we use regularly at OpenLogic are: Prototype, script.aculo.us, TinyMCE; Firefox, Firebug, YSlow; Ruby, Rails, Capistrano; Apache, MySQL, Hyperic, and dozens more.

Don't Be Afraid of JavaScript
JavaScript, the scripting language in which AJAX function calls are usually made (hence the J in AJAX), may be intimidating but developers shouldn't be frightened. With Ruby on Rails, there are view helpers that wrap AjaxRequest for convenience and facilities like RJS to update multiple areas of a page. These are both ways to avoid writing ugly boilerplate JavaScript. But it's important not to be afraid of writing JavaScript by hand, including filtering, sorting, adding form fields, and manipulating small data sets on the client. This kind of JavaScript is fairly straightforward and will dramatically improve the performance of your application because it avoids round trips to your server. It's important to think in terms of client-side JavaScript for actions that users will naturally and reasonably expect to happen instantaneously.

Watch Out for JavaScript Conflicts
If you choose to implement a lot of third-party components on your pages, expect to run into JavaScript conflicts. Unfortunately, JavaScript libraries are still the "Wild Wild West," and there aren't many real standards yet. As an example of compatibility issues: if you need to use both Prototype and jQuery on a single page, probably because you want to use components that depend on each of them, run JQuery in "no-conflict" mode to avoid conflicts with Prototype. This is an easy one, since there's a trivial workaround, but sometimes there's no simple solution. For example, the live validation library provides nice client-side form validation, but it takes over the form's "onSubmit" hook, which makes it hard to implement custom submission logic or to use other components that also want to use onSubmit. Use JavaScript libraries, but remember that some prudence in your initial selection will save a lot of painful debugging down the road.

Client-Side Validation Is Hard, but Worth It
Developers should show, hide, and populate fields dynamically. Counting the remaining characters in text areas is important because it prevents user frustration during submission. Default values in certain fields set context and let user visualize results. For example, if you have a complex form with a field called "Business reason," the default value could be something like, "Please justify your need for the open source package you're requesting." In other words, provide the help text right in your form field. This also makes it easy for users to visualize the form completed and is therefore more likely to get through it without giving up entirely. Now you have to do the hard part of clearing or ignoring the default value during form validation, possibly changing the font for non-default values and the like. It's hard work, but users will really appreciate your effort.

Cross-Browser Issues; Not Too Bad
Certainly use a framework like Prototype or jQuery to make your life easier. This will get you at least 90% of the way to cross-browser compatibility. Note that you still have to deal with issues like some browsers truncating tooltips whereas others wrap. In these cases, developers should use another library, some custom JavaScript, or perhaps even AJAX to enforce consistency (e.g., replace the standard tooltip with your own detailed informational popup like you might see at Netflix or Blockbuster). For CSS, developers may need special browser checks if they really care about width details. Margins and padding can be treated differently in IE versus FF. As a rule of thumb, use the latest version of a mature framework like Prototype and don't worry about cross-browser issues until they come up in testing.

Security Must Be Implemented in All Layers
With AJAX, developers must pay special attention to security, since the attack surface area is larger. The easiest way to deal with AJAX security is to simply assume that every AJAX request is just as public as your home page. Secure your application as if every hacker has the full API spec in front of them and knows everything you know about your application - nothing is secret. Therefore, you should never ever trust any input, such as URLs, hidden fields, form values, cookies, POST data, etc. And when it comes to Web applications, don't create a hard shell with a soft chewy center. In other words, client-side validation is only for user convenience; check all roles in your controllers and implement all data validation and security in your models. It's more work this way, but a multi-tiered approach to security is always your best bet and will make it far easier for you to open up a Web Services API to your application in the long run.

Testing Is Crucial
AJAX is difficult to test because it requires complex interaction between a browser and a server. This means you have to augment standard unit and functional tests with in-browser tests. Open source tools like Watir, FireWatir, and Selenium can run your tests right in the browser via JavaScript, which means they can truly test your AJAX-enabled application in the context of a user. The more of these automated regression tests you have the easier it will be to upgrade JavaScript libraries and add new components to a page without spending days debugging conflicts. As a specific tip, make sure your AJAX actions change the CSS class of at least one HTML element when they finish. This way, your tests can trigger the AJAX event, sleep for a second, and then check the element's class to make sure it changed. Here's a gotcha to watch out for - in certain browsers, programmatically triggered events don't always work as you would expect. To work around this issue, write a utility function that fires more events than are strictly necessary (e.g., when changing the value of a form field, fire the events "onSelect," "onKeyDown," "onKeyUp," and "onChange" to make sure any JavaScript listening for changes definitely gets notified).

Conclusion
Users are coming to expect more from their online experience. By making Web applications feel like desktop applications, AJAX is delivering on that expectation. However, AJAX is not a silver bullet. It should be used in moderation and not shock users. A number of tools, especially from the open source community, make it easy to provide seamless AJAX features without forcing developers into proprietary technology or ugly generated code. It's important for developers to learn some JavaScript to avoid mindless code generators and to write client-side script when it's better suited for the task than roundtrip calls to the Web server. As with any new enabling technology, security and testing are absolutely critical and should not be implemented as an afterthought but rather baked right into the development process from day one. Armed with these lessons learned, now is the time to implement AJAX judiciously in your next Web application.