Evented Programming With jQuery(yehudakatz.com)
yehudakatz.com
Evented Programming With jQuery
http://yehudakatz.com/2009/04/20/evented-programming-with-jquery/
3 comments
Did the Ruby community just invent the term "evented"? I've never seen it used elsewhere until recently.
While there is some good stuff here, my first reaction to the idea of "evented programming" as described here is that Katz has simply replaced a perfectly good language-level mechanism for OO-inheritance (the prototype chain) with a library-level mechanism - using jQuery event triggers to implement a kind of AOP-style "before advice" - that makes the code both harder to read and to debug.
Can you imagine using Firebug to step through the chain from the first click event to the "base" implementation of "activate" in this example, through all of the jQuery event triggering going on? Nasty.
Am I missing something here?
Can you imagine using Firebug to step through the chain from the first click event to the "base" implementation of "activate" in this example, through all of the jQuery event triggering going on? Nasty.
Am I missing something here?
It seems to me (an avid jQuery user, no less) that people are stretching the paradigm too far. There are places where traditional, class-like abstractions are perfectly legitimate, and indeed more natural. Some of the more elaborate applications of jQuery, such as jQuery UI, come across as smelly to me -- sometimes plain old classes and objects are nice.
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.
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.
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.
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.
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.
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.
This is what happens when Microsoft picks you up and says here this is how we do it.