If I’m thinking right (and I admit I very well could not be), if I use an array and iterate over it in some sort of loop/foreach fashion, and call a method on them to take their action, they would run sequentially, but if I notified them to update via some sort of triggered event, then the sequence of execution isn’t necessarily sequence in array (which doesn’t matter in this case), and also doesn’t block me from completing whatever I have to do in this controlling widget’s interval.

It seems like that’s one thing a non-UI-driven event gives me — the ability to kick off methods on an indeterminate amount of objects without having to wait for execution of all of its slave widgets. Given that this event has to happen on a fairly regular interval, it seems like an event-driven approach might be better, even though I am fully aware of what’s in my array and could just go down the list.

Am I think of this right? (I realize I’m speaking very vaguely, but I’m hoping it’s enough to be clear.)

I think, in general, especially at the scale of usual implementations in typical web pages, yes, you’re absolutely right.

Question is (and I don’t pretend to know the answer) using this proscription, could we create gMail or Google Docs or EBay or Amazon.com or things beyond mere-mortal scale? I’m not so sure.

Another consideration: when you code-crash in a mainline JS application, you’re likely scuppered. If you crash in a trigger implementation, trigger functionality aside, you’re likely fine. (Again, generalities…)

So I sense that, at-scale, or in systems built by composition (jQuery-UI being a convenient example) it’s hard to imagine not using custom events.

I found very interesting this video from Nicholas Zakas:

http://developer.yahoo.com/yui/theater/video.php?v=zakas-architecture

The idea is to build a modular structure, where every module knows as little as possible of the surrounding environment.

But I agree that if you are one coder working on one project this sounds more as a waste of time and performance.

Here’s 2 examples I find all the time:

1. A representation of the data model is changed (ex: a file deleted).

There might be multiple representations of the same file on the page. With JavaScriptMVC, models use OpenAjax.hub to publish events. It’s possible for widgets on the page to listen for these events and act accordingly.

Doing this without OpenAjax would be rather annoying. Each widget would have to add a callback to some structure (which is effectively open ajax), or the response code would have to look up each widget and tell it what happened. All this is much easier by having the widget subscribe to “file.deleted” events.

2. Widgets triggering ‘change’ with their value.

In an app I am working on right now, there are toggle-able sections and other widgets that have some important UI state that needs to be saved between visits. I have all widgets triggering (w/ jquery) a ui.state.change event with their new value. I listen on the document for ui.state.change events and send updates to the server.

The great thing about this approach is that we can build any widget to produce ui.state.change events and it will automatically work.

I find that widgets triggering a “change” value is extremely common and useful. I also find having that making widgets respond to Activate and Select allows me to customize how they are used easier.

But all this said, it is very easy to take events too far.

With more native events in the browser, it becomes easier to implement an events-based application architecture pattern, which, while being just another way of doing things, might actually be preferable to some people.

Having recently experimented with events-based application architecture patterns myself, I can definitely see some benefits to that approach. For example, through DOM event bubbling (and ideally, capturing as well), ancestor and descendant elements can be “coupled” through only their hierarchical relationship, which can help to generalize and reduce code.

Yeah, even with my experimentation, all I did was log that data was changed. Beyond that, you get into a much more complex world of, “Oh crap, data was changed… now what?”. And that, becomes a lot of work.

I know very little about FLEX; but, they do things like binding an ArrayCollection to a DataGrid; then, when the array data changes, the DataGrid *automatically* re-renders. This is done, in part, by data-binding. BUT, the really super powerful stuff – the re-rendering – has nothing to do with data binding at all really (form what I can break down). For the people coming from a FLEX world, I think the allure of “data binding” is that they are getting confused as to what does what.

@Brian,

Yeah, definitely there are great uses for non-UI events. Interacting with video players is a great one. I use to play with Flash and the video playback module in Flash has all kinds of timeline events that you can bind to.

I suppose one could make an argument that objects firing events like “I was changed!” means you can write theoretically more modular code, because then Object A doesn’t need to be aware of Object B, so when A changes, B can just listen in, and A can remain un-coupled, but it seems to be little more than a theoretical argument with no real meaningful application.

I’ve been dabbling with the video tag and canvases lately for fun, and I have found that some non-UI events in that area are kind of nice. The video pops play and pause events, and while typically those actions are associated with user interaction, if a video is set to autoplay, there’s not any interaction at the outset, so having the video say “Hey, I’m playing now!” has been really handy. Given load times, there’s no real way I could just wait a predetermined amount of time for it and then say “Okay, we must be playing now”, and while it’d be easy enough to write a polling timeout, that feels kind of ugly.

It seems like it’s about knowing the right tool for the job, and being able to recognize that while one can do some neat things with events, it doesn’t mean they necessarily should, just like anything else we do.

when one object *should* know about another object, there’s no need to announce anything – you simply need to invoke methods.

Yes, exactly. That’s really the only reason why I take issue with this new event-driven frontier. Copious callbacks and events are all the rage now but eventually using it so much will become an anti-pattern. I just hope developers think carefully before jumping on (or off) the bandwagon.

I haven’t yet looked into the Flex framework, so I can’t comment on that, but I’d love to see some realistic demos of data-binding in languages like JS/AS — all the ones I’ve found so far are pointless… just console-logging when a piece of data is mutated.

I recently tried to experiment with some data binding stuff, with FLEX as the inspiration. It is interesting, but I think people will lose a bit of the fascination when they realize that listening to data changes is only a *tiny* part of the battle. The real hurdle will be responding to those changes and smartly re-rendering the layout… which has nothing really to do with data binding at all.