Often I have been asked which JavaScript library I prefer over all other, and the answer is not as easily orated as one might expect. Occasionally, I actually find someone willing to spend the time and thought involved with seeing the answer through to its conclusion. To avoid any undue future banter, I thought I would put my thoughts concerning the matter down in writing and simply reference this post when the topic is breached.

No, this will not be a comprehensive discussion and review of all available JavaScript libraries, but hopefully it will be sufficient to drive people to view the topic with a bit more of an open mind. Also, I must alert those who have come looking for a definitive answer from me: you will not receive a single library of choice here, but rather you will be given some insight to different perspectives requiring careful consideration when each library is being reviewed.

Now, for those who are adamant about having a definitive answer – and before I’m shot by certain library purists, I will definitely narrow my scope of recommendation to two libraries: jQuery and ExtJS. Before you berate me for being indecisive in my conclusions, let’s consider some perspective in development that may drive us to either one of these wonderful libraries.

First, let’s consider jQuery as an option. A very concise, descriptive and accurate overview of the library can be found right on the library’s homepage:

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating and Ajax interactions for rapid web development.

Obviously, the goal of the library is to speed up development time while offering an ease of custom manipulation within an incredibly lightweight footprint – a mere 19K for production. What’s more, with the CSS selection model and amazing shorthand John Resig and crew have implemented, it also significantly reduces the footprint of the actual code that has to be written for your site. In my experience, jQuery is definitely the easy choice for basic, lightweight DOM manipulation, traversal and other aspects so clearly defined in their purpose statement above.

On the other hand, I also find myself using ExtJS significantly as well – often in the same apps with jQuery. As strange as this sounds, upon examination of the ExtJS library (really more of a framework in my opinion), we can see very distinct pros and cons for its use in certain circumstances. While the entire Ext SDK is quite sizable (9.6MB zipped), one must also understand this includes a myriad of support files for GUI and customizing components beyond simply JavaScript source files. Yes, Ext introduces us to a whole new realm in web development: giving us the capability to generate fluid “Rich Internet Applications” (or RIA), as they are called on the Ext website, within minutes. Rather than having to spend hours and hundreds, if not thousands, of lines of code to build robust GUI interfaces with a basic manipulation library, like jQuery, fully customizable and “skinnable” themes are at your fingertips with Ext already.

So, this brings us to the dilemma of which I mentioned at the outset: which to use? They each have very distinct strengths, and in fact, it is even possible to use an Ext build based on jQuery for its core. My personal recommendation: use them both – within reason. One of easiest ways to distinguish between libraries, as with any other code or application decision, is to examine both your need and the scope of the library in question. If you are in need of a robust way to handle administrative interfaces or administrative-like tasks, or if you are simply interested in a unique way to turn your user experience into a more desktop-esque environment, a framework like that of Ext may be well suited for you. On the other hand, if you are simply looking to do manual DOM manipulation or event handling from within the scope of individual pages, jQuery would probably be the poison of choice.

Now, some of you may be wondering about the combination of the two to which I referred early in this post. For my current job, I am responsible for spearheading the UI development for an internal CMS our clients use to publish their portal pages. Herein lies a very interesting challenge: keep the admin interfaces crisp and clean while publishing robust actions to the portal pages that focus specifically on minimizing the footprint of those published pages. So, as you may have surmised by now, I get to live in the best of both worlds. Using Ext for our CMS was really somewhat of a no-brainer. Generating modularity within the CMS and allowing for accessing multiple controls from a singular entry point was very easily obtained by basing our UI off the robust framework offered. By spending a couple days to create a theme to match our corporate look and feel, we are golden.

However, when it comes to the published portals, the issue of code footprint relevant to dynamic content rears its ugly head. Trying to publish out the supporting Ext framework elements is a bit heavy – even with a custom build – for the little dynamic GUI we display. In the long run, we end up much better off with the basic jQuery library and developing our own custom plugins that both trap user events and manipulate the DOM in very specific ways on those pages. This is also a case where the speed of the CSS selector within jQuery once again proves useful. By reducing the processing time of individual manipulations and being able to generalize the scope of our custom plugins while still reducing our footprint, the choice is clear. To try and build the entire JavaScript framework needed on the internals of our CMS on top of jQuery, though, would prove not only difficult but incredibly time consuming as well.

All in all, I have settled on both of these libraries as viable options, dependent upon your environment and requirements. I have yet to find another library that exceeds both of these in any of my personal scenarios, though I am starting to give YUI 3 some attention due to many of the new features as well. While this does not definitively answer the question of what library one should use – nor can this question ever be a dogmatic answer for everyone, I hope it lends itself to challenging the reader to examine every individual circumstance and application as a whole. Generally speaking, there is a best fit for each scenario; though in some cases, the time required to learn a new library may outweigh the benefits of choosing a new one.

Suffice to say that, with a little thought, instead of becoming a slave to routine, you can make your libraries work for you, which I believe is exactly what the authors of those libraries intended from the start.