5 ms·

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 se

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.

ZitchDog 12y ago
Because node is single threaded, so blocking for this user will block all requests for all users.
- BonoboBoner 12y ago
  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 12y ago
    it's because native threads are expensive
    - BonoboBoner 12y ago
      They are again? In this talk they mentioned them to be cheap in 2008
olalonde 12y ago
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)#Preemptive_multitasking http://en.wikipedia.org/wiki/Preemption_(computing)#Preempti...
- BonoboBoner 12y ago
  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 http://www.mailinator.com/tymaPaulMultithreaded.pdf

ZitchDog 12y ago

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

BonoboBoner 12y ago
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 12y ago
  it's because native threads are expensive
  - BonoboBoner 12y ago
    They are again? In this talk they mentioned them to be cheap in 2008

olalonde 12y ago

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)#Preemptive_multitasking http://en.wikipedia.org/wiki/Preemption_(computing)#Preempti...

BonoboBoner 12y ago
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 http://www.mailinator.com/tymaPaulMultithreaded.pdf