I don't find it natural to access data via callbacks, especially since data is usually connected (e.g. you need to query for the user, then the settings and then the item):

The node.js documentation also illustrates an example of this when doing sys calls:

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

vs.

    posix.rename("/tmp/hello", "/tmp/world").wait();
    var stats = posix.stat("/tmp/world").wait();
    sys.puts("stats: " + JSON.stringify(stats));

As I understand it the event loop in node.js does not get blocked by calling wait().

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.

I guarantee that we'll see people developing applications in JavaScript that run client side, using this under the hood, and they will have no idea how bad an idea this is from a security point of view.

There are good reasons that the classic website setup has the database on a different machine than the webserver firewalled in such a way that the database cannot talk directly to machines on the internet. As time goes by and attackers improve in sophistication, those reasons are becoming better, not worse.

Tangent: The theme of the blog is extremely cool. Been playing with the movable clouds for a few minutes now-where'd you get the idea for that?

Except the fact that the contrast on the actual content is bad. Darker backgrounds and lighter text has been proven to get read less (60+% more if it is lighter background and darker font). The clouds are cool but the contrast is not.

This type of contrast is good for entertainment (movies, video games etc) not code samples. Even if you have to go with a dark background and light text make sure it is not extreme. A good sample of a dark site that is contrastually(I made that up) readable is : http://www.smashlab.com/ OR add a 'high contrast' button that you can click such as on: http://www.merixstudio.com/

Trust me when you get older than 27 you'll thank me.

I foresee a series of posts, "_____ from Node.js", where the blank is filled with any mundane technical action that is necessary to build web sites. Each one, like this one, will demonstrate how writing Javascript in continuation-passing style is the way to do things in a "non-blocking/evented" manner.