> Also, don't think non-blocking is really non-blocking. What can nodejs when it's waiting for the SQL lock to be lifted? (If there is any)

Node has a queue of stuff in the form of an event/message loop. It simply takes the next thing in the queue or it goes idle. That's why in Node you generally try not to do computational intensive tasks, because they hold the queue and it can't take any new requests.

- Correct. I am saying that nodejs is slower in general. The reason you would use nodejs is to save development time, and not to extract the last drop of performance. It is for the same reason that people have written so many apps on Python and Ruby.

- I/O in nodejs is always asynchronous. I/O in typical .Net apps is almost always synchronous, due to programmer choice. This approach is followed in the vast majority of Asp.Net apps. So according to you, this would imply that most .Net programmers don't know how to program in .Net.

- I can't follow how "ORM magic" is related to I/O. The ORM magic I remember has been a terrible experience for me when I had to use .Net (3-4 years back). We have to write our own ORM to replace EF, since it was dog slow. Including the LINQ expression tree parser, design-time tools etc. You can find this result here: https://github.com/jeswin/AgileFx

I know that things finally got better after EF4. But I haven't worked much on .Net of late.

Node has threads behind the scenes. The average developer can touch them. As a result, you can make 3 async calls with node and you end up only waiting on the slowest. As a result when the slowest returns you've got all the data needed by the controllers/views. Thus your overall system improves.

You could do this with ASP.NET MVC if you're not using the databindings on the front end and your willing to make your service layer a bit more complex. The code behind could call the service layer, which in turn calls three async methods (futures) that would return your data set. Then the service happily chugs along once it's got its data. This just isn't normaly in .NET world.