At 12:16 in the following video by Philip Roberts, he talks about the Web APIs and Node APIs running on different threads than the call stack, if I am understanding him correctly? So, is this correct, do the Web APIs and Node APIs run on different threads than the call stack and event loop?

If true, does this mean that they will run in parallel to JavaScript being executed in the call stack?

At 12:16 in the following video by Philip Roberts, he talks about the Web APIs and Node APIs running on different threads than the call stack, if I am understanding him correctly? So, is this correct, do the Web APIs and Node APIs run on different threads than the call stack and event loop?

If true, does this mean that they will run in parallel to JavaScript being executed in the call stack?

https://www.youtube./watch?v=8aGhZQkoFbQ

• javascript

Share Improve this question Follow asked May 11, 2018 at 0:26 CazineerCazineer 2,41544 gold badges3131 silver badges4747 bronze badges 8

• Sort of, but the effective result is NO. What he said is that "the run time can only do one thing at a time". He then repeats this several times. The Web APIs and Node APIs (this is V8 specific) run in separate threads; but, when interacting with the runtime, they must inject themselves into the stack (or event loop) within the single thread of the runtime. Meaning, all those tasks are effectively running in the one thread that the run time is limited to. – Randy Casburn Commented May 11, 2018 at 0:34
• He does state that the "the run time can only do one thing at a time" but then states that the Web APIs "are effectively threads that you cant access like threads you can just like make calls to..." then, clearly shows setTimeout taking place within the Web API and when pleted, the Web API pushing the result into the event loop, which then gets pushed into the call stack. I've watched this video multiple times and my interpretation is when setTimeout for example is called, it's executed in the Web API and then the result pushed in the event loop, no different than an API request... – Cazineer Commented May 11, 2018 at 0:58
• 1 Yes, your interpretation is correct. The browser optimizes performance in a Muti-threaded way, but your JS app is still constrained. So the effective overall result is still constrained by the path of most resistance - the single thread of the JS runtime. Unless you use WebWorkers :-) – Randy Casburn Commented May 11, 2018 at 1:04
• I think I understand what you're saying, you're saying that even though the Web API or Node API is doing some work in parallel on a different thread, a JS app is still constrained by the fact that the result of that work, ends up in the event loop, which then pushes the result into the call stack, when the call stack is finished doing the work that is currently in it? Nothing can happen until the call stack is empty. – Cazineer Commented May 11, 2018 at 1:10
• Yes....Exactly! – Randy Casburn Commented May 11, 2018 at 1:11

 |  Show 3 more ments

2 Answers 2

Sorted by: Reset to default 8

Short Answer: Yes.

As has been pointed out in the ments, Web APIs "are effectively threads" although with a different behavior and purpose.

And, finally, the result will still be accessed and limited by the single "threadedness" of the JavaScript runtime when whichever callback is pushed into the Call Stack.

Yes, the execution of the web-API happens in parallel in another thread and when the execution is plete, the result(or callback) is pushed onto the task queue, and when there's nothing on the call-stack, the event loop picks this result(or callback) from task queue and puts it on the call-stack.

The execution of the web-API code itself happens on a separate thread but the code that works with the result executes on the call-stack.