Why jQuery Died
jQuery as many of you probably already know, is a widely accepted javascript library with a focus on making javascript development easier and faster for designers. Prototype has also been a library that was made popular by Ruby on Rails and CakePHP developers since the library was not only included and made easily accessible by these frameworks, its acceptance in the web development world was fast and thorough. We’ve recently gone through an exercise to standardize on one javascript library to be used across the company in all our future development work. The battle for which library should be used had begun. The short of it is jQuery lost…but not without a fight, nor without much discussion, debate and frustration.
Pertinent Background Information
At work, there are two departments that focus on the website(s); the Creative team (of which I’m a member of) and the Engineering team. While the Engineering team is focused on the features and user-experience of the ecommerce side of the company (card selection, personalization and customization, form processing, checkout, etc), the Creative team is focused primarily on the marketing and front-end/UI side of the company (pretty images, SEO modifications, promotional banners, ease of navigation, site design and colors, etc). Creative’s development cycle has an extremely fast turn-around, whereas the Engineering team is slower, but releases more…substantial changes. As you can see, both departments are essential to the overall success of the company and as such we are very complementary — one cannot exist without the other.
When I first started a little over a year ago, the Creative team was small and relied pretty heavily on Engineering resources whenever there was a need for any javascript development as no one knew how to write (good) javascript code. This put an unnecessary strain on Engineering to help us whenever there was a need. We were equally (and unnecessarily) burdened, so a decision was made to start implementing the use of jQuery (which I knew) to help rapidly deploy some quick enhancements to the site (like image rotators, input clearing, and other similar tasks).
As you can imagine, this was going to eventually lead to problems with the $ (jQuery’s and Prototype’s) sign (what’s the dollar sign for?) as both Prototype and jQuery like to use this guy…it was just a matter of time.
A fellow developer summed it up perfectly like this:
As far as these two go, I think the main difference is that jQuery offers a cleaner DOM selection/manipulation experience, as well as a large base of library and community plugins/widgets. I find it to be more of a designer’s library, where with very few lines of js you can achieve very good results for enhanced UIs.
Prototype, on the other hand, may be a bit more verbose (selection, chaining and so on) but I find it to be more of a programmer’s library, it seems to offer a more complete environment where more complex applications can be developed (a class mechanism, a nicer binding mechanism for closures). In many ways Prototype seems like an attempt to transform javascript in to a more standard OO language while providing a good starting framework.
Put jQuery into noConflict() Mode
You might be asking, why not just put jQuery into noConflict mode? That was my argument as well! That would solve just about everyone’s problems and jQuery would still be used. The only issue it wouldn’t fix, is the one where we wanted to standardize on one library.
Business Objectives and Compromises
Since both libraries accomplish the same tasks with essentially the same speed and efficiency (learning-curve not included), the decision was made that for the betterment and longevity of the company, the library to be standardized on would be Prototype.
In the end, the decision didn’t come down to which library is better or worse, or what does the industry think or say is better or worse, but what makes the most sense for our situation. As the company continues to grow, and more widgets and technologies are tacked on to make things better, it just made sense to standardize now on one framework so we can use widgets created from either side of the company on other pages.
Additional Thoughts
This brings to mind a similar thought regarding other choices made in life (maybe expanded upon in another post…?). Often, as people we choose one thing over another based on personal choice without figuring what the best solution really is. In this example, the argument could be (and was) made that the majority of the web developers in the world resort to jQuery as their library of choice (I would venture to guess around 60-70%). Though this does lend credibility to the maturity and stability of jQuery as a potent framework worthy of serious contention, it doesn’t necessarily equate to what is best for the business. There has been significant time (and money) invested in developing features in Prototype and would require another significant amount of time (and money) to reverse this and change everything over to jQuery.
Regardless of this decision, jQuery is still my library of choice and will continue to be used in all my personal projects outside of work… Long Live jQuery! Please, if you have any additional thoughts, let your comments be heard — I’m interested in what you all think!