What is the difference between different ways of Custom event handling in JavaScript?

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)

• How do I create a custom event class in Javascript?
• http://the.unwashedmeme.com/blog/2004/10/04/custom-javascript-events/

2. Custom code

• http://www.nczonline.net/blog/2010/03/09/custom-events-in-javascript/
• http://www.geekdaily.net/2008/04/02/javascript-defining-and-using-custom-events/
开发者_如何学Python

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?

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

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.

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.