I'm having trouble visualizing how Javascript can be both single-threaded but non-blocking on the client. I've always envisioned something like an assembly line:
At the start of your code execution, you've got a single assembly line putting together different parts to a car.
We get to a point at 20%-to-completion where an engine needs to be added, but an engine hasn't been assembled yet.
Instead of waiting for the engine to be assembled, the assembly line gets broken up into two assembly lines - two threads, right?
Line 1 continues to assemble the other parts of the car.
Line 2 starts to assemble the engine.
When Line 2 finishes the assembly of the engine, it goes back into Line 1 and the engine is added.
Line 1 could be at 30%-to-completion, 99%-to-completion, etc at this point depending on how fast the engine was assembled.
This is how I envisioned non-blocking, async code. The main thread of Line 1 gets to continue to chug along without having to wait for Line 2 to finish first. But this assembly line metaphor requires two assembly lines, or two threads, but JS is single-threaded.
So now I'm confused.
In short, the runtime has an event loop that kinda simulates async in 1 thread. In long, I found this video and text to be a good explanation: http://2014.jsconf.eu/speakers/philip-roberts-what-the-heck-is-the-event-loop-anyway.html