[nakajima]

Traditional object oriented programming is certainly easily at first, especially to those with a strong background in it. Unfortunately, in every app I've ever worked on, there's a dissonance between OOP and the browser environment that causes things to break down, at which point it becomes incredibly difficult to salvage without a re-write.

After working on some really complex JavaScript applications, my opinion is that the approach Yehuda's advocating in this post is enormously helpful when applications start getting complex, both in terms of the DOM as well as the behaviors that apply to them.

[allertonm]

It seems to be the fashion to bash OOP these days, but I wonder in this case whether by "OOP" you are really talking about attempts to emulate classic GUI programming in the browser. In which case, I completely agree - and one of the things I love about jQuery is that it lets you work with the browser like it's a browser.

In this case I think Katz is replacing one kind of abstraction off of the browser with another one, actually an abstraction away from the natural call mechanisms of the javascript language. This is basically Aspect Oriented Programming by another name, and I've not actually come across a project where AOP made life less complicated.

[nakajima]

The way I look at it is actually less AOP than it is event-driven SOA. All of your domain-specific event handlers are sort of like services.

[njm]

I personally advocate a two-pronged approach, where DOM manipulation is done via jQuery (at which it excels), but abstractions are built up via classes (pick your favorite implementation). This avoids overextending either paradigm.