The company I work for, Uversa Inc., is based around General Public License (GPL) software, so when I pick any library, it first needs to be compatible with the GPL. Because the GPL is so widespread, many licenses are compatible with it. (See www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses for more information.) However, because licensing is a hard rule, you should always start your search by limiting it to the ones that meet your needs. After getting my license guidelines, I look at major features that are required. In my case, this includes good compatibility with PHP, including the ability to map data types between PHP and JavaScript. I also want to be able to easily combine the library with other JavaScript libraries, so well-name-spaced functions and variables are a plus. Finally, I want a focused design, so I'm looking just for an AJAX library; I don't need a large JavaScript framework that takes weeks to learn. Multiple developers will be using it, so the less they have to learn, the better.

During most of 2005, these requirementsand a bit of searchingwould have left me with a small list of libraries from which to choose. I could investigate them and find one that fit the rest of my Web development framework without too much hassle. Today, though, these requirements leave me with a large list, so I need to enter some other items to narrow the list of items I'll investigate thoroughly. I can further limit my list by picking projects that are actively being developed, so I'll look in depth only at those with releases in the past few months and that seem to be developed by more than one person. You don't want to remove every single-developer project (after all, that's where many of the most innovative ideas come from); you just want to make sure that enough releases have been made that the library is not a one-time code drop of unfocused ideas. These criteria will help weed out the unsuitable projects and will keep me from wasting time on a project that will never gain the community needed to sustain it over the long run.

Once I have a short list of libraries, I'll do a quick review. Everyone has different goals, but I like libraries with at least basic documentation and an object-oriented (OO) design. (OO design is especially important to me on the PHP side because it will need to mesh with my existing code.) A good way to test any library is to do a basic install and to build a basic "hello world" application with it. If you can't easily complete a basic task, then the library probably isn't a good fit. AJAX isn't such a complicated technology that the basics can't be made easy while still making the difficult items possible.

Hopefully, after some basic use, one of the libraries will stand out from the pack and end my search. If a few libraries seem really good, I'll dig further into their documentation and user forums and make a final decision based on how easy learning all the details will be. If none of the libraries looks like it will work, then I'm left back at the starting gate. I can expand my search and look for less popular and hence harder-to-find libraries, or I can look into developing my own solution.

In my earlier searches, I had very few options when I was selecting a library; my first foray into AJAX was before the term had been defined. I picked the JPSpan library for its good PHP integration and object-oriented design. Although JPSpan was a decent solution, it didn't end up meeting all my needs. Over time, I decided to develop my own library, HTML_AJAX, for PHP's PEAR project. The reasons for building my own library relate more with wanting to help the PEAR community than in meeting my needs, but once you have your own library, it's an easy front-runner for future use.

As you make a decision on what library to use, you can apply much of this process. First, decide on your licensing needs; your needs can be as simple as a specific open source license or as complicated as a commercial solution. After that, look at your feature requirements, especially server-side language support, and build a list of possible solutions. If the list is large, looking only at more active projects is a great way to pare down the list. Then, take some time to investigate the libraries. I find it's always worth my time to actually write a small amount of test code. After that, it's just a matter of picking a library that seems like a good fit. Don't forget to take into account everything into which you'll be integrating this library; some solutions that might be easy in a standalone situation become a bear when integrated into your server-side Web development framework.