Funny, because I avoid putting CPU intensive code in any request handler... in any language. if the calculation takes time, it's better done async.

(and I don't even use node)

Wait, I think I've missed something because that response seems overly dismissive. How is offloading CPU-intensive stuff to a worker system not getting it done?

because you dont fix everything with another layer of indirection. add in some more queuing (which as we know never has a problem) just to ger around 'no threads' seems stupid.

um...the whole thing with asynchronous event-based processing is that you can (ideally) dispense with threads for many use cases.

You will have to do more of it, of course.

In a classic thread-based system, it's okay if a single page takes a bit longer (e.g. >1 sec) to render if it's within your user's line of expectation.

You can't do that here because you'll block all the others.

But any decent developers knows that, so he takes the advantages Node.js offers and fixes the disadvantages that come along with it. Big deal.

Is this discussion really only about the scalability tagline? Some taglines are misleading, really?

That comment sort of destroyed all your credibility. Would you care to elaborate where in the "real world" there is ever a situation where a tight, asynchronous event-processing loop is required to do heavy CPU lifting?