Although the Javascript/V8 runtime does a lot, the browser consists of more than just that. So even though JS itself is single threaded, browsers/node can support non-blocking asynchronous code.
The browser consists of multiple things:
One thread, one call stack, one thing at a time As functions are executed, they are pushed onto the stack As functions are returned from, they pop off the stack
Async callbacks are the solution to blocking the call stack so that things can keep executing.
This is where setTimeout actually comes from, its not part of Node/V8/JS/etc. This is responsible for AJAX requests, XMLHTTPRequest, DOM events, etc.
When setTimeout is called, it moves to the call stack, and then creates a timer inside of the Web API section (thread pool?). Once this timer has finished, it pushes the callback onto the callback queue.
Finally there's the evnet loop which is rather simple - it looks at the stack and the task queue. If the call stack is empty, it pushes the first thing in the task queue onto the call stack, which makes it run.
—
This explains why setTimeout with a delay of 0 doesn't run immediately. It must first travel through the task queue and evnet loop, which means it can only execute once the call stack is clear. The delay isn't a guarantee, it's closer to a minimum delay.
Event handlers are also in this realm of web APIs also. They exist outside of the call stack, and then when triggered will add a new task to the task queue that will be eventually picked up in the event loop.
The browser can't render until the call stack is clear - it almost acts as an async callback. However it's given priority over your tasks in the task queue.
'Don't block the event loop' is basically saying don't create slow code that blocks this event loop, as the browser needs to re-render.