It depends what you are doing. If you are implementing some web application I can imagine that this callback style would be very handy.

For example, suppose you have an email application and on the page there's an area with contact information. You could fire off the SQL query to get the contact database and have the callback populate the contact information box on screen when it's ready.

The rest of your program just carries on doing whatever it needs to do: which may be nothing... the entire program can be event driven and waiting for events to happen (like the user clicking somewhere).

This style of programming takes a little getting used to, but you don't need to have some linear piece of code going around checking to see what needs to happen next.

If in the example of contact information you need something else to happen once the box is populated then I imagine you'd fire some event that tells your program what to do.

I agree on the usefulness, but I don't think it would produce more elegant code and I don't think the event driven paradigm should be used for everything (even if there are some advantages).

This said, event driven programming is quite natural when doing network or GUI programming and most good network and GUI frameworks are event driven. Most database libraries or system libraries aren't.

I'm currently working on porting dojo.Deferreds to node.js. On top of them I am also working on some API sugar that makes it really easy to aggregate the results of multiple deferreds:

    (group)
      ('a', db.query('SELECT A ...'))
      ('b', db.query('SELECT B ...'))
      ('c', db.query('SELECT C ...'))
      .addCallback(function(results) {
        p(results) // {a: ..., b: ..., c: ...}
      });

This will make it very easy to run multiple things in parallel, yet handle all of them in one callback.

Check http://github.com/felixge/node-deferred for more info.

Do not use wait() too much, it will be memory expensive.

Deferred[1] is originally used in Python's Twisted framework. It's also used in Bob Ippolito's MochiKit's library. Generally, it's a great abstraction and I am looking forward to see your results. As I recall Twisted has an ability to chain deferrers.

[1] http://twistedmatrix.com/documents/current/core/howto/defer....

The whole point is that they innately bind to one another -- they are, after all, monadic (gasp!)

It's very easy to define bind and return for event driven code, so most event driven programming is or can become monadic.

As the API docs note, wait() can be problematic: "If any other promises are created and made to wait while the first promise waits, the first promise’s wait will not return until all others return. The benefit of this is a simple implementation and the event loop does not get blocked. Disadvantage is the possibility of situations where the promise stack grows infinitely large because promises keep getting created and keep being told to wait()."

You could get around the lack of naturalness by using something like MethodChain [1] to allow you to write code like this:

    posix.rename("/tmp/hello", "/tmp/world")
    .stat("/tmp/world")
    ._(function() {
        sys.puts("stats: " + JSON.stringify(this));
    });

http://jsclass.jcoglan.com/methodchain.html

Is there example of how to create this worst case scenario?

Try not to use wait() like this.

There was recently committed writeSync, statSync, etc. that perform POSIX API calls synchronously.