jQuery vs. Prototype: OO JavaScript with or without training wheels

After brushing up on jQuery via a little light reading, I've started to play with the framework in code. I'm demoing a scrolling news ticker and decided to write it using jQuery and its Interface plug-in. Future iterations will probably include the history and easing plug-ins, too. In the meantime, though, it's been two steps forward, one step back. I really dig the elegance of the jQuery API and its concise method-chaining. But there's one integral element of the Prototype/Script.aculo.us framework that I miss: The Class object and the OOP training wheels it provides.

For developers like myself - long-time UI folks who have used JavaScript's Object datatype for years but lack significant experience writing in a strongly typed, truly object-oriented language like Java - Prototype has been a revelation. It doesn't enforce OOP principles, but it encourages them. And its source code is like a Rosetta Stone for how to implement them in the dynamically typed, prototype-based world of JavaScript.

There's been lots of discussion over the past year about the deficiencies of Prototype's inheritance scheme. A lot of the syntax is ugly, and Object.extend is easy to overuse or misuse. The new 1.6.0 release candidate appears to address some of those weaknesses by augmenting the Class object's API. Regardless of your position on this debate, though, it's hard to ignore the fact that Prototype has helped a lot of front-end folks improve their half-assed understanding of OOP. Personally, I wouldn't even be in a position to follow the discussion if I hadn't spent the last 18 months or so writing Prototype-backed JS classes. Thanks to the patterns to which this library has exposed me, my grasp of JavaScript - and of software engineering in general - has grown by leaps and bounds.

Once I started using a different library, though, Class.create was suddenly useless. I had to figure out different inheritance and encapsulation strategies. The training wheels were off, and I had to find my own of balance. My first hurdle was figuring out how to organize my jQuery procedures into reusable methods. I felt totally adrift without the built-in ability to bind functions to their execution environment; the this keyword was always assigned to a DOM node. I thought about simply porting Prototype's Function.bind and Function.bindAsEventListener methods, but that seemed at odds with the design of jQuery's own API. Finally, I turned to Douglas Crockford's module pattern for JavaScript. Now I had a new way to organize my objects and methods in a reusable way that worked well with jQuery. By defining private methods inside of a closure, I could access those methods with simple function calls, no binding necessary. As with Prototype, a whole new world opened up.
   

A lot of developers worry that Ajax frameworks make for lazy programmers, but in my experience the opposite is true. Each new design pattern or framework that I play with teaches me new approaches to JavaScript and OOP in general. Folks coming at UI development from, say, a C++ background may want a framework that enables a well-defined inheritance model. But OOP scaffolding is a separate concern from Ajax and DOM tools. Prototype provides both, while the base jQuery library provides only the latter. Still, somebody could easily write an OO plugin for jQuery - or several of them, each implementing a different inheritance model.

Simon Williamson's recent post on jQuery for JavaScript programmers does a good job of explaining how jQuery encourages good OOP techniques. The walled-off namespacing represents a different conceptual model from Prototype's. Until you understand both, it's difficult to see all the strenghts and weaknesses of either. As with other tool, the key to these frameworks is learning what tricks and tradeoffs each one supplies, and why. Up next: YUI and Ext.

Related Services:
Ajax Rich Internet Applications, Custom Software Development