7 ms·
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
by nakajima 17y ago
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.
- njm 17y agoI 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.
- allertonm 17y agoIt 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 17y agoThe 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.