[BonoboBoner]

Interesting comparison. I have never used Node for anything bigger than small personal stuff, because non-blocking code was never a requirement. I still dont see the value in it in scenarios like in the blog post, as all he is doing is a bunch of functions and once all of them are done, send something back to the client.

How does the client or the dev benefit from the non-blocking approach here? At the end of the day he is describing a sequence of actions the depend on each other. Why not block then?

I really dont want to sound arrogant, but I am just curious what the benefits are that I dont know of.

[olalonde]

Originally, for performance reasons. Async code lets you handle multiple concurrent connections without having to rely on multiple threads or processes (which are more resource hungry)[0].

Nowadays, there's also the fact that if you want to use Javascript on the backend, Node.js is the de facto standard. You don't necessarily have to do async I/O but you'd be fighting against the whole ecosystem by not doing so.

[0] http://en.wikipedia.org/wiki/Preemption_(computing)#Preempti...

[BonoboBoner]

I agree that is is the standard way of doing things. I was just curious why the trend moved towards this approach. Not a long time ago Concurrency based on a lot of threads had an upswing.

http://www.mailinator.com/tymaPaulMultithreaded.pdf

[ZitchDog]

Because node is single threaded, so blocking for this user will block all requests for all users.

[BonoboBoner]

That explains it, thanks. To me this makes the focus on non-blocking code in PlayFramework2.0 a bit more strange to me, since the JVM isnt single threaded.

[yowmamasita]

it's because native threads are expensive

[BonoboBoner]

They are again? In this talk they mentioned them to be cheap in 2008