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

Brian Dillard has written about his experience playing with jQuery after time as a Prototype-r.

The piece walks us through Brian’s understanding of JavaScript and OO as he worked with different libraries:

Learning from Prototype

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.

Learning from jQuery

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.

(Via Ajaxian.)