title: What's the magic about event driven?
body: <p>After reading several posts about event driven and nodejs, the only advantages I can see are that event driven avoids the memory allocation for threads and replaces polling with notifications where possible.</p>
  
  <p>The other advantages are all arguable:</p>
  
  <ol>
  <li><p>Multithread program is easier to make mistakes than single thread.</p>
  
  <p><strong>Argue:</strong> for web applications, requests are independent from each other, as long as the handler functions has no side effect; if all the IO parts are handled by database servers, there is nothing to worry about multithreading.</p></li>
  <li><p>The event driven approach will not block on IO, and thus could handle more requests. This advantage seems the most important feature of event driven. And in <a href="http://code.danyork.com/2011/01/25/node-js-doctors-offices-and-fast-food-restaurants-understanding-event-driven-programming/" rel="nofollow">this</a> example it is compared to the doctor offices, which I think is not proper. </p>
  
  <p><strong>Argue:</strong> In the doctor offices example, receptionist do not wait for a patient to fill in the forms, but serves the other patients while the previous patient is filling the form. This is a misleading example. </p>
  
  <p>a. If we interprete patients as clients sending request to the server. The server of course will not block for the clients to fill in the forms in their own browser. And when the clients finish the forms and send a http POST to the server, then the server will start working. The web has already been an event driven system before nodejs exists. So this example is not valid to explain server side event driven programming.</p>
  
  <p>b. Someone would say that we should interprete the patient filling the forms as the server side IO intensive operations. But the difference is: we don't pay for the patients to fill in the forms, but we pay for IO intensive operations.</p>
  
  <p>So my argue is that, even the time consuming operations are not blocking your current thread, there's gonna be some other thread, or process or database server blocked. I see many times that nodejs can serve 10k concurrent connections because it is none blocking. I would say that, if there are not enough other threads or processes or servers to handle the time consuming part, it would not be possible.</p></li>
  </ol>
  
  <p>In this case, event driven is nothing more than load balancing using nginx, except that load balancing balances the request to applications, while the event driven balances the request to time consuming operations, which moves the load balancing layer backwards. And the only advantage of doing so are the two I mentioned in the beginning of this question: 1. it avoids the memory allocation for threads. 2. replaces polling with notifications where possible.</p>
  
  <p>Thank you for reading to this point, my question is: is my understanding correct? Any mistakes I made in my argument?</p>