Agree people don't understand the contexts under which a node.js type system is useful.
Personally, I think there are a million better options than server-side JavaScript.
The author of the actual post that the OP is responding to did not quite get what async behavior meant in node.js - i.e. it's less to do with using process.nextTick() to buy you parallelism, and more to do with async I/O.
And, there are other server-side JavaScript engines than just node.js (although it's only node which is getting all the attention), so I wouldn't be making such a generic statement.
Is it easier to write performant code with node.js vs Java Async IO? Subjective.
(Or just use Twisted and Ampoule. Seriously, guys.)
Their documentation is a joke, they managed to completely gunk up their architecture with a crudely bootstrapped attempt to solder interfaces onto python, and their development community is not particularly...welcoming...to newcomers.
Suffice it to say that when the only real way to get anything done with a framework is to read the source and then ask questions in their IRC channel, then something is very, very wrong.
I'm sorry you don't like zope.interface. Do you prefer ABCs? What would make interfaces better for you? Did you prefer Twisted's builtin interfaces to zope.interface?
How was the community unfriendly? What can we do to improve the community experience?
(Anecdote: The only way I've been productive with Django is through reading their source; their IRC channel and documentation are useless.)
1. The basic part of the system is a single thread running an event loop. It has a queue of waiting events. Every time the event loop starts, it pops off all of the waiting events and then gives your code a chance to process them, one after the other. Once your code is done processing this batch of events, a new even loop starts. Any events that occurred while your code was running will now be processed.[1]
2. Some kinds of work take place outside the event loop. I/O tasks such as sockets and file reading/writing are good examples. In Node.js, I/O calls automatically spawn a new thread, which goes off and does whatever task you wanted it to do. When it finishes, it pushes an event onto the event loop's event queue, which will be handled by the event loop the next time it starts a new loop. Other things, such as TCP servers, run perpetually in their own thread, but will push new events onto the event queue whenever something interesting happens (receiving new data, etc.).
3. You, the user, cannot do work outside the event loop. You cannot spawn threads. That is something that the framework does automatically, and only for certain, built-in tasks like file I/O. Node might add support for arbitrary asynchronous work later on, but for the moment this is not possible.
4. Remember from #1 that a new event loop only starts when the previous event loop has completed. Since an event loop is essentially "the code you have written to process events that you care about", if any of that code takes a very long time to complete, then there won't be another event loop for a long time. Any new events that occur during that time (such as new HTTP requests) will not be processed until a new event loop occurs.
[1] Exception: events that your code emits are processed immediately.
One thing to note is that it's not inefficient. You will be maximizing your CPU's and will be processing work as efficiently as possible, but users will experience some requests having a variable response time. This can happen any time you have a pool of generalized worker processes btw, it's not just a "node thing".
Solutions? If some requests do significantly more computation than others, you can split the computation in half using process.nextTick(). This will let smaller requests go faster in exchange for the slower request going slower (remember, we're already at max efficiency, so it's not like everything is going to get faster). This is better than sending the work out to a separate process unless the job is so big that the serialization/IPC cost is negligible. Otherwise you're adding extra work and making everything slower.
But really, having to manually chop up your algorithms is kind of a special case. Most requests in your app probably take the same order of magnitude in terms of computation time, or they are obvious outliers (pdf generation, video encoding, etc) that you would want to move to a separate process.
If you have two sets of requests that have different orders of magnitude then put these two sets on their own node worker process behind your load balancer.
As long as you send your requests to the worker process that handles requests of a similar order of magnitude you will never have the faster requests being stuck behind slower requests problem.
