6

I came across the below posts about custom event handling in JavaScript. From these articles, there are two ways (at least) of handling/firing custom events:

  1. Using DOM methods (createEvent, dispatchEvent)
  1. Custom code

But what is the recommended way of handling (firing & subscribing) custom events?

[Edit] The context for this question is not using any libraries like jQuery, YUI,... but just plain JavaScript

[Edit 2] There seems to be a subtle differences, at least with the error handling. Dean Edwards ( http://dean.edwards.name/weblog/2009/03/callbacks-vs-events/ ) is recommending the former way for custom event handling. Can we say this a difference?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
manikanta
  • 8,100
  • 5
  • 59
  • 66
  • Are you using any frameworks? JQuery and YUI both have event handling built in. – Zoidberg Jul 04 '11 at 10:59
  • I use both jQuery & YUI in my project and I've used them many a times. But I m interested in to know the custom event handling without using any libraries. Thanks. – manikanta Jul 04 '11 at 11:02

3 Answers3

5

What your describing is the difference between

  • A custom event based message passing system
  • manually firing DOM events.

The former is a way to use events for message passing. An example would be creating an EventEmitter

The latter is simply a way to use the browsers build in DOM event system manually. This is basically using the DOM 3 Event API which natively exists in (competent / modern) browsers.

So the question is simply what do you want to do? Fire DOM events or use events for message passing?

Benchmark showing DOM 3 custom events is 98% slower

The DOM appears to have a huge overhead. It does so because it supports event propagation and bubbling. It does because it supports binding events to a DOMElement.

If you do not need any of the features of DOM3 events then use a pub/sub library of choice.

[Edit 2]

That's all about error handling, how you do error handling is upto you. If you know your event emitter is synchronous then that's intended behaviour. Either do your own error handling or use setTimeout to make it asynchronous.

Be wary that if you've made it asynchronous you "lose" the guarantee that the event handlers have done their logic after the emit/trigger/dispatch call returns. This requires a completely different high level design then the assumption that event emitters are synchronous. This is not a choice to make lightly

treecoder
  • 43,129
  • 22
  • 67
  • 91
Raynos
  • 166,823
  • 56
  • 351
  • 396
  • I want to use the custom events for pub/sub mechanism, like whenever the 'Send' button is clicked and the message is sent to the server, I want to publish 'msgsent' event and the listeners which were bind to that custom event would be called then. This helps me maintaining the loose coupling between the event created code and the sequentially executed code (listener code). Thanks – manikanta Jul 04 '11 at 11:17
  • @mrCoder the DOM appears to have a rather large overhead. Use a custom library, I recommend EventEmitter because it's used in node.js – Raynos Jul 04 '11 at 11:46
  • Ahh, Thanks for the benchmark Raynos. I guess I should use ay pub/sub library then. Any idea about other libraries compared to EventEmitter? And any guess on the Dean Edwards suggestion (I edited my question to include his blog post link)? – manikanta Jul 04 '11 at 12:08
  • @mrCoder that's implementation specific. It's a question of whether you want the events to fire sychronously in order (i.e. blocking) or asynchronously in order, or asynchronously without order. That's a completely different discussion. There are side-effects to making the event emitter asynchronous. – Raynos Jul 04 '11 at 12:17
1

There are pros and cons to each. Use what suits you.

The most obvious "con" to using the DOM methods is that they're tied to browser-based deployments and involve the DOM in things even if it doesn't really make sense (e.g., the messaging isn't related to DOM objects), whereas a standard Observer-style implementation can be used in any environment, not just web browsers, and with any generic object you like.

The most obvious "con" to doing your own Observer implementation is that you've done your own Observer implementation, rather than reusing something already present (tested, debugged, optimised, etc.) in the environment.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • He may actually want to manually fire DOM events, rather then using the in build DOM events as a custom pub/sub system. – Raynos Jul 04 '11 at 11:05
  • @T.J. Crowder Thanks for the answer. But do you've any idea about performance difference when talking about the hundreds of events fired/subscribed by different elements simultaneously, if any? – manikanta Jul 04 '11 at 11:06
  • @Raynos No, I want to fire a custom event, say like, 'msgsent' when a message is sent. Thanks – manikanta Jul 04 '11 at 11:08
  • 1
    @mrCoder: I don't, sorry. I can speculate, but usually when one speculates about JavaScript performance in particular scenarios, one ends up looking like an idiot. :-) What's fast on one implementation is slow on another; what seems reasonable because of past experience with other languages turns out to be unreasonable applied to this language, etc. Rarely has the statement "don't optimize prematurely" been more applicable than to JavaScript, and particularly JavaScript on browsers. Best, – T.J. Crowder Jul 04 '11 at 11:11
  • 1
    @T.J.Crowder you should know that DOM3 events have a lot of magic build into them (bound to elements, propagation, bubbling) and are therefore always slower then a lightweight custom implementation that just does message passing. – Raynos Jul 04 '11 at 11:54
  • @Raynos: Yes, though if you fire them on `document`, there's virtually no propagation or bubbling. I'm just saying, predicting performance diffs in JavaScript on browsers is a mug's game. :-) If one is worried about this approach vs. that approach in perf terms, I'd just encapsulate the logic for hooking up the handlers (since that's quick and easy), pick the approach that had the features I wanted, and be prepared to change it if and when I had a perf problem. I could pre-test perf on http://jsperf.com or similar, but even that feels premature compared to deciding on features/effort. :-) – T.J. Crowder Jul 04 '11 at 12:22
0

Many libraries already provide a way to deal with events, and I would recommend on just using an existing library. If you use the DOM, you are assuming that the browser provides the necessary support, whereas if you use a custom mechanism, you might be sacrificing speed for the custom implementation. If you rely on an existing library, the library can choose the appropriate tradeoffs.

For example, Closure provides EventTarget which has an interface simliar to that of the DOM mechanism, but which does not depend on the browser to provide native support for it.

Michael Aaron Safyan
  • 93,612
  • 16
  • 138
  • 200
  • Yeah, as I mentioned, I m aware of the libraries like jQuery & YUI from a long time. But I just want to know the subtle differences between these two approaches. And, though I doubt the cases, in sometimes we can't use jQuery just for the sake of custom event handling or pub/sub mechanism. Thanks. – manikanta Jul 04 '11 at 11:20