I’m currently using Prototype for my project(s).
http://www.prototypejs.org/
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:
- Click button
- Load page
- Select some options
- Load second page
- Enter data
- Click Save Button
- 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:
- Build our own library
- 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?",
"answers":[
"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.