Ok, so it is opposite in nodejs? There's a single JS thread but as soon as it performs any async IO ( which is the only IO that one should be performing in node ), that IO creates a thread servicing that IO request. In addition to that, if one is crazy enough to run long computational operations there's setTimeout(), setImmediate() and process.nextTick() and friends.
Though I would say it doing any real compute work inline rather than farming it out to workers is a boneheaded idea regardless of the language used.
AFAIK there is only ever just one thread (that runs user code). setTimeout, etc are all also invoked by the event loop.
I can vaguely recall (but it's 1AM so I didn't verify - take with a grain of salt) that nodejs uses an a thread pool for IO, but I guess that's only for IO for which there is no async API, otherwise that would be wasteful.
I imagine a quick search about the event loop and said thread pool would yield better researched answers :)
Nodejs is single process, single thread and single core. Chrome used to run different tabs as threads of a process but that ended since Spectre and Meltdown. Back to single process since then.
async IO creates a thread servicing that IO request
Nope. The event is a single FIFO queue implemented with libuv. It differentiates between sync and async function and basically goes around the queue running synchronous functions to completion every time it find one and async ones for a set time before switching to next one.
Though I would say it doing any real compute work inline rather than farming it out to workers is a boneheaded idea regardless of the language used.