> Realistically, it's impossible to wait or block an I/O request while at the same time also letting the other part of the code engage in other tasks, that's th

> Realistically, it's impossible to wait or block an I/O request while at the same time also letting the other part of the code engage in other tasks, that's the very definition of multi-threading. Doing "async" is impossible without multiple threads in that sense. Node must have a thread pool of sorts where one of them is engaged in the wait/block while another is running your JS code further. When the wait is over, the control is then passed to the "event handler" function it was bound to in that other thread. > What Node is selling as "single threaded" applies to application or business logic we are writing, node itself can't be single threaded. I've questioned the same thing in the past and have been confused about it too. Node itself runs in a single thread, but my understanding is that calls on external APIs to do IO which would then run in their own thread because this would typically be managed by the OS. While Node is waiting on those calls to finish and call the callback method it can go execute another event that was waiting in the meantime. Then when that's complete assuming the original IO call has now responded it will continue to execute that code by running its callback. I could continue trying to attempt to explain why you're wrong poorly, but honestly I haven't read into this in years and my understand even then was just good enough to satisfy my own curiosity. I think it might be worth reading more about how Node works. > I feel it's better to just implement multi-threading in your own code (as needed) instead of using something convoluted and confusing like Node.js. Skipping over the fact Node isn't multi-threading, the advantage as I understand is that Node is faster at handling requests since there is no over heading in spinning up and managing threads for each incoming request. I also remember reading that Node tends to perform better when handling very large amounts of concurrent requests. The reason for this if you have a sudden spike in incoming requests you'll need a server which can spin up hundreds threads a second then attempt to process those requests simultaneously. Node on the other hand doesn't really care because it will just continue to handle each request as fast as it can in a single thread.