[j2d2j2d2]

I agree. It's interesting to see node fans get huffy when Erlang people say, "hey, we're still #1"

But for people who already love JS, node is a dream come true. It's really fast. Not as fast as Erlang, but more than fast enough to justify building massive projects in it. Assuming you are one of those that loves, or believes in, JavaScript...

[forensic]

Don't you find using callbacks for everything to be a straightjacket?

[j2d2j2d2]

Personally, yes. I like to use eventlet in Python partially because of that. Interacting with the scheduler is implicit in eventlet (and gevent, which some prefer) so you write code that looks synchronous.

On top of that, you get nonblocking I/O almost for free, similar to what node attempts to provide, where instead of real nonblocking I/O the system will make blocking I/O look like it's nonblocking. Scala does this too.

But, users of Twisted could also use inLineCallbacks for a similar feel, though it's not required. I'm curious if Node.js could just build the same?

[stock_toaster]

There are some nice libraries that ease the pain of callbacks to a certain degree.

Async[1] (the waterfall method) and Step[2] come to mind.

[1]: https://github.com/caolan/async

[2]: https://github.com/creationix/step

[forensic]

This pretty much spoils the whole idea that you'll use your clientside JS on the server though, huh?

The callback issue means that client and server are really not running the same language. They sorta look the same I guess.

[yesbabyyes]

I'm not sure about step, but caolan's async is perfectly usable in the browser, as well as in node.

That said, code sharing between browser and server often extends to templating, validation and a few utilities, in my experience. More complex logic is better served with message passing or something like dnode.