JavaScript Library Summary

The point of this thread is to be a comprehensive summary of the available javascript libraries - but with a twist.

Most threads I’ve seen thus far with regards to libraries are:

  1. Which one is the ‘best’ ?
  2. Poll: Which library to you prefer and why?
  3. Here’s a quick breakdown of all the libraries

Inevitably, responses to these threads are short “jQuery rulz” or “Prototype is too big” or “You can’t forget Mootools” responses that end up falling short of what the OP is typically looking for.

Let’s break out of the mold and make this thread different. Each response should contain a comprehensive summary of the poster’s experiences with their favorite library. Try to include things like:

  1. Which library are you currently using for your project?
  2. What other libraries did you consider and what made you decide on Library X?
  3. What problems/successes did you experience with Library X as part of your implementation?
  4. What are your recommendations for someone trying to decide on a library with regards to library X?

That should be a good list to work from, but is by no means complete. As the thread gets bigger, I’m certain we’ll end up with a huge compendium of solid, real-world experiences for just about all of the libraries out there!

I’ll post the first response to demonstrate what I mean. Hopefully this can become a good resource for people new to the world of javascript libraries and possibly point them in the right direction in making a choice.

I’m currently using Prototype for my project(s).

Before getting into the “why I chose prototype” section, let me provide a little bit of background for the project I’m working on.

My employer currently utilizes a CMS that they inherited from the late 90’s. The system, although antiquated, does the job for which it was intended and has been doing so for awhile. “If it ain’t broke, don’t fix it”, right? As the needs of our business has changed over time, so has the needs of the CMS. For many years, the Web 1.0 methods have worked fine:

  1. Click button
  2. Load page
  3. Select some options
  4. Load second page
  5. Enter data
  6. Click Save Button
  7. Finish task

Recently, however, the change requests from our business partners have become more and more complicated. Web 1.0 model wasn’t going to work. We had to build several “Rich Interfaces” to enable some of the more complicated business requirements.

For example, the business needed a means to create ad-hoc surveys - with the ability to search for and reuse questions/answers from other surveys, the ability to copy questions/answers and edit them as ‘new’, and create new questions/answers on the fly. A Web 1.0 application to locate, assign, and save these surveys would have been too bulky and required way too many clicks to get around.

There were additional requirements such as the ability to create/read/update/delete various tree structures (and nest them) for navigation of certain learning materials.

Based on these requirements, we were faced with a couple of choices:

  1. Build our own library
  2. Use one that’s already out there

As most IT folks know, rolling your own is time consuming. In addition, the accounting folks NEVER want to pay for all that development time. Option 2 was our choice, so we did some research. There are many many other libraries out there that we looked at, but only a few were given a more thorough review (listed here in alphabetical order):

I’m not going to express in any great detail how each library “stacked up”, but here’s a very short list:

  • Dojo - we did’t want to build a bunch of widgets and it encourages invalid markup. OTOH, they have really good accessibility stuff.
  • jQuery - too DOM focused. Not enough ‘behind the scenes’ OOP for us
  • Mootools - all about the visuals. Too little focus on OOP
  • Prototype - not as sugary as jQuery and no built-in visuals; but the extensions to the JavaScript core were perfect for what we needed
  • YUI - We didn’t need any of the widgets and our bosses weren’t convinced it was really free to use.

While the eye-candy was important, we really needed some heavy-hitting on the client-side to process a lot of data. For example. One feature in our survey tool was the ability to create/edit questions. We created a question ‘class’ and bound it to certain icons’ click events:

var Question = Class.create();
Question.prototype = {
  initialize:function(id,params) {
    //some initialization stuff
    Event.observe($('q_icon' + id),'click', this.clickFunction.bindAsEventListener(this));
  clickFunction:function() {
    //do stuff to this object's params

When a question was created, we did something like this:

var something = new Question(numericId,{
  "txt":"What is your quest?",
    "We seek the holy grail",
    "To find a shrubbery",
    "I want to be in grave danger",
    "To discover huge tracts of land"

Anytime the ‘edit’ icon was clicked, for example, the closure to the question object would allow us to directly edit that object’s parameters without having to search for it in the DOM or elsewhere in some ‘master’ object.

While prototype’s Ajax.Request object isn’t any more grand than the others, we do enjoy the Ruby-esque means to loop through the returned JSON from searches:

returnedArray.each(function(result) {
  //do stuff to display results and build objects

Beyond the client-side processing of objects, we don’t need any animation, so a simple $(‘elementName’).hide() or .show() is sufficient.

For implementation, our first hurdle was the download. Prototype is pretty big. After we minified it and enabled gzip on the server, it was reduced to around 30KB; much more palatable and kept the bosses happy (we pay for bandwidth)

The second hurdle was the learning curve. Many developers would consider JavaScript to be a toy language meant for rollovers and alert boxes.

I think the biggest benefit to using prototype is now our code has some commonality. Everyone on our team knows how to use .each, $(), and just about every other method/extension that prototype provides. The common code base makes it a lot easier to read each others’ code (especially if someone is on vacation) and there’s no bickering over which library is better. While it’s great that jQuery would do better for feature A and YUI has a better widget for feature B and mootools has a cool accordion; it’s far less hassle when everything is based on a single library.

If you’re trying to decide on a library, I recommend prototype for the following cases:

  • You need more than just an API to make DOM traversal easier
  • You don’t need any animation or special widgets (popup calendar, autocomplete, etc)
  • You have a server that can gzip files
  • Your application needs to process a lot of data on the client side

I’ve purposefully avoided bringing in Scriptaculous to this discussion because we’ve considered it more of a ‘fringe benefit’ to Prototype rather than an integral part of our needs.

There you have it - my reasons for (currently) using prototype.

It’s called jQuery UI: It’s more than just graphical extensions, it’s a library of widgets that allow you to rapidly build rich internet apps.

Hi there,

I am a huge fan of jQuery and Dojo. I am working a lot with Dojo right now.

One issue I have with prototype is that it rewrites some of the global namespace - such as array. When you use prototype you get their arry - not a plain old javascript array - and you have no choice.

One thing I like about Dojo and jQuery is that they respect the global namespace - for when you just want JavaScript, but both offer powerful features. As I’m working with Dojo’s object oriented architecture to create some fairly robust apps - I am liking it more and more.

The coolest thing is Extjs… i know it’s a resource killer but they have there something amazing

  1. Which library are you currently using for your project?

The X Library.

  1. What other libraries did you consider and what made you decide on Library X?

I didn’t consider any other libraries. X is my own library so I’m more comfortable with it than with someone else’s. That’s not to say that I don’t make use of other people’s open-source code - I do when the need arises. And of course, I do study the source code of other libraries ;).

  1. What problems/successes did you experience with Library X as part of your implementation?

Recently I developed a fully Ajax enabled “Dashboard” type application (think “google analytics”) for my employer, and X has served me extremely well in this project. I didn’t have any real problems in using X to do this but it did reveal some areas where X could be improved.

  1. What are your recommendations for someone trying to decide on a library with regards to library X?

If you are looking for syntactic sugar or lots of UI objects or OOP support - then X is not for you. X is a straight-forward, function library. It is very small, extremely cross-browser, and robust (I’ve been developing it since 1999). The “core” DHTML functions provide a great foundation upon which to build your own objects. You don’t have to include the entire library into your project - I provide a utility that searches your project files and creates a custom X library file containing only the functions used in your project.

BTW… if you are the copy-n-paste type, then X is definitely not for you :wink:

I absolutely love YUI, with all of the extensive documentation, and proper implementation of design patterns, and emphasis on OO and event driven approach to JavaScript. To me, YUI is a whole JavaScript resource and coding philosophy.

Now if you just want a really great collection of scripts that require less engineering prowess … I’d go with JQuery, hands down. Different tools for different teams. :slight_smile:

To me, YUI is for a serious engineering team and pairs great with a Java/MVC backend. JQuery will be a lot more reasonable to PHP and probably a lot of .Net developers as well, who are more scripters/coders than engineers per se.

I would generally avoid Dojo or Prototype, or Rico.

Best Library Ever.

A good overview of available JS libraries: