Can the execution of an xmlhttprequest request be considered work in a separate thread?

Question

JavaScript

Hello everyone and Merry Christmas!
In an interview, I was asked a question regarding Javascript multithreading. I hung up, but my answer was that JS can be considered multi-threaded and I assume so due to the presence of xmlhttprequest requests (in common ajax). The question is about threads, not to be confused with asynchronous code execution.
Question: Is WebAPI related to the JavaScript engine and is it correct to say that xmlhttprequest actually runs on a separate thread from the rest of the JavaScript code?

Related Resources

Кроме отличных овтетов, нашел замечательную серию из 19 статей на хабре, в которой объясняется в том числе и то, о чем этот вопрос. Найти ее вы сможете по заголовку: "Как работает JS: обзор движка, механизмов времени выполнения, стека вызовов" (не реклама, а помощь будущим поколениям)

Answer 1

Disclaimer:
With web workers (and something like that) everything is already clear, so I write further outside of their use
The answer to your question depends heavily on the understanding of the title. If we are talking about the browser or some part of it, then it is quite likely that this is really work in a separate thread. Only this is a browser job , not javascript. For example, here is an article about node.js https://codeburst.io/how-node-js-single-thread-mec... (just read Top Highlight)
Thus, node.js can be said to be a multi-threaded application. But from the point of view of javascript, that is, as if from within it - node.js is single-threaded. In other words: all JavaScript code both in the browser and in the node positions itself as a single-threaded application. And it does the same. But some operations outside the language (I / O or the same xhr) can be implemented as you like by the browser. This is strictly speaking a question more about the design of the runtime environment.
- Not. This is the API that the browser provides inside the engine. This can be traced by taking for example node.js and comparing it with browser js. So, for example, internal modules (fs, http, path etc.) are available in node.js, as well as other features such as process.argv and so on, while the browser has WebAPI, such as fetch. At the same time, there is no require('path') in the browser, but there is no fetch in the node.
And this despite the fact that both the browser (chrome) and node.js work on the same engine (V8).
In node.js, there is no access to xhr, which may already suggest that this is not part of the engine.
Important note: I think by comparing node.js and the browser, you can get some idea of ​​what a pure js engine is, but nevertheless this is not completely reliable. Because, for example, both there and there are setInterval and setTimeout compatible with each other, however (if my memory serves me right) they are not included in the engine.
If you want to clearly understand where the border is, but not so much to read the specs, you can try to build the engine yourself. V8 or SpiderMonkey (in Firefox) can embed into other applications, and if you embed them yourself - and the API inside the engine (and its specific implementation, and not an abstract concept) will need to be passed on by yourself - then you can see that in the bare engine there is no there will be neither setTimeout, nor alert, nor console.log, nor document, nor even require, etc.

Answer 2

Introduction to HTML5 Web Workers: The JavaScript ...