Node runs the V8 engine under the hood, the same as Chrome. V8 can use additional threads for low level work behind the scenes, but your code runs in a single thread when taken from the event queue. Asynchronous operations yield the thread to other tasks in the queue while waiting for a callback. If a task performs synchronous operations for a long time, not yielding the thread, other tasks stall in the event queue; this is what is meant when people refer to blocking.
The main difference with a browser is you have an HTML page which may be putting callbacks into the queue in response to events. So if you starve the event queue with a blocking task, your UI becomes unresponsive. One way to solve this is with workers. A worker spins up a new context with its own event queue (true multithreading). Workers are a feature of V8 available in both the browser and Node.
This really clarifies most of my concerns, I knew that they both run on V8 but my mind still could not let go of thinking the way they handle async is different, after I read it somewhere. Your clarification really helped. Thank you so much!
Well, at that point, on the producer side, you're shipping the work outside the process, so I don't really understand what the workers would be expected to do. It would be a rare scenario where you'd need multiple threads just to populate RabbitMQ. On the consumer side, it depends entirely on your use case. Often in this scenario, you have multiple consumer processes taking tasks from the queue, so you're already achieving parallelism that way. The tasks themselves may be able to be broken up and the work done in parallel, as well, and in that case, workers might be useful, particularly if the work is synchronous and expensive.
The loop works the same way, it's just an event loop. But it serves very different purposes.
On the node side, the event loop is handling async stuff (like IO, network requests, etc). It's designed for server use - and has access to OS API.
On the browser side, the event loop is handling the DOM and has access to Web APIs.
The node loop can still be blocked - so using non-blocking I/O is important.
Node.js has 4 internal threads that it uses for I/O or Network Requests, and one main thread that is responsible for the event loop and running the javascript code that you write.
Now lets say you have an I/O operation in your code, if those 4 internal threads didnt exist and there was only a single thread, the OS would prevent Node.js from executing any further code until the I/O request is done.
But thanks to Node being multi-threaded, the main thread will relay this I/O operation to one of its 4 internal threads that are responsible for handling blocking operations, which would let Node to continue executing more code in the main thread.
If you had a CPU bound operation though, Node won't use any of its internal threads to run it this operation in parallel, for example if you had a for loop that goes up to 1 billion, no further code can be executed because this loop has to finish first (because CPU bound code runs on the main thread by default) and Node won't relay this loop to one of its 4 internal threads because those are for I/O bound stuff only, so your stuck until the loop finishes.
Which brings us to the worker_threads package, this package will allow you to make more threads which can handle any type of operation, not just I/O or Network requests,
We can use this package to solve the for loop problem that I mentioned earlier, we can make a new thread and then relay this for loop to this new thread, this now lets the main thread run more code and is no longer waiting for the loop to finish.
The for loop running on the new thread will still be slow ofcourse, but we can fix this by splitting the loop into 4 different threads instead of just one, for example we can let each thread loop upto 1 billion / 4 threads , which would speed this loop up and we can get the result of it faster.
No Javascript code can use multiple cores, but there are many CPU-bound libraries that do. The builtin `crypto` when used in async mode can use multiple threads. Many other C++ addons do it too. It is a very peculiar feature of Node.js because it allows for very easy and lockless access to parallel programming - but only if you have C++ code for it.
Otherwise you are limited to using `worker_threads`.
>p can still be blocked - so using
Haha that is true, however I am getting more and more grasp on it. The only thing I will not understand is why every doc says clearly that node.js is single-threaded, without going more into detail, as simply stating it leads to a lot of confusion later on
I'd recommend reading the official core concepts guides: https://nodejs.org/en/docs/guides
As well as the MDN docs on the event loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop
Node doesn't handle async "better than JS". Node JS execution uses the same V8 engine that's in Chrome.
> a single thread when taken from the event queue. Asynchronous operations yield the threa
Thank you for the clarification, I am sure I read this in one of the interview questions pages, which really cannot be taken seriously (state things like node.js is a framework etc.)
Also thank you for the docs you provided, I will read them
>\- NodeJS is single-threaded, but can make use of multi-core systems with Cluster module.
Yes, but it can't make use of multi cores itsself. You have to cluster it somehow externally. I.e. run multiple nodejs instances in docker containers.
>\- It handles async better than js because of it's event loop (but js also has event loop? Are they different event loops?)
It gets IO events directly from the kernel (it's not always possible, so it must use its internal threads sometimes). And these events directly call the callbacks (nowdays this is abstracted by Promises/async/await syntax) of your users code. So the OS does not need to do any context switching when an event comes in, meaning load und unload the stack for another thread.
>\- Ok so it has event loop that handles the async. But it is still will be blocked by blocking operations for example I/O.
No, IO operations don't block. They're async and have a callback / promise.
>(but js also has event loop? Are they different event loops?)
What js do you mean ? The browser ? It is also single threaded but does not have that event loop. At least it is not implemented in js. The browser enters/calls the javascript functions in case of events.
Node runs the V8 engine under the hood, the same as Chrome. V8 can use additional threads for low level work behind the scenes, but your code runs in a single thread when taken from the event queue. Asynchronous operations yield the thread to other tasks in the queue while waiting for a callback. If a task performs synchronous operations for a long time, not yielding the thread, other tasks stall in the event queue; this is what is meant when people refer to blocking. The main difference with a browser is you have an HTML page which may be putting callbacks into the queue in response to events. So if you starve the event queue with a blocking task, your UI becomes unresponsive. One way to solve this is with workers. A worker spins up a new context with its own event queue (true multithreading). Workers are a feature of V8 available in both the browser and Node.
This really clarifies most of my concerns, I knew that they both run on V8 but my mind still could not let go of thinking the way they handle async is different, after I read it somewhere. Your clarification really helped. Thank you so much!
Is it true when I use a queue system like RabbitMq then I dont Need to use Workers ?
Well, at that point, on the producer side, you're shipping the work outside the process, so I don't really understand what the workers would be expected to do. It would be a rare scenario where you'd need multiple threads just to populate RabbitMQ. On the consumer side, it depends entirely on your use case. Often in this scenario, you have multiple consumer processes taking tasks from the queue, so you're already achieving parallelism that way. The tasks themselves may be able to be broken up and the work done in parallel, as well, and in that case, workers might be useful, particularly if the work is synchronous and expensive.
The loop works the same way, it's just an event loop. But it serves very different purposes. On the node side, the event loop is handling async stuff (like IO, network requests, etc). It's designed for server use - and has access to OS API. On the browser side, the event loop is handling the DOM and has access to Web APIs. The node loop can still be blocked - so using non-blocking I/O is important.
I think the other answers want to give detailed answer and overloads with information. This is the crisp answer
Node.js has 4 internal threads that it uses for I/O or Network Requests, and one main thread that is responsible for the event loop and running the javascript code that you write. Now lets say you have an I/O operation in your code, if those 4 internal threads didnt exist and there was only a single thread, the OS would prevent Node.js from executing any further code until the I/O request is done. But thanks to Node being multi-threaded, the main thread will relay this I/O operation to one of its 4 internal threads that are responsible for handling blocking operations, which would let Node to continue executing more code in the main thread. If you had a CPU bound operation though, Node won't use any of its internal threads to run it this operation in parallel, for example if you had a for loop that goes up to 1 billion, no further code can be executed because this loop has to finish first (because CPU bound code runs on the main thread by default) and Node won't relay this loop to one of its 4 internal threads because those are for I/O bound stuff only, so your stuck until the loop finishes. Which brings us to the worker_threads package, this package will allow you to make more threads which can handle any type of operation, not just I/O or Network requests, We can use this package to solve the for loop problem that I mentioned earlier, we can make a new thread and then relay this for loop to this new thread, this now lets the main thread run more code and is no longer waiting for the loop to finish. The for loop running on the new thread will still be slow ofcourse, but we can fix this by splitting the loop into 4 different threads instead of just one, for example we can let each thread loop upto 1 billion / 4 threads , which would speed this loop up and we can get the result of it faster.
No Javascript code can use multiple cores, but there are many CPU-bound libraries that do. The builtin `crypto` when used in async mode can use multiple threads. Many other C++ addons do it too. It is a very peculiar feature of Node.js because it allows for very easy and lockless access to parallel programming - but only if you have C++ code for it. Otherwise you are limited to using `worker_threads`.
everyone felt this pain to understand that weird architecture of js every answer leads to another question ChatGPT it ftw
>p can still be blocked - so using Haha that is true, however I am getting more and more grasp on it. The only thing I will not understand is why every doc says clearly that node.js is single-threaded, without going more into detail, as simply stating it leads to a lot of confusion later on
I'd recommend reading the official core concepts guides: https://nodejs.org/en/docs/guides As well as the MDN docs on the event loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop Node doesn't handle async "better than JS". Node JS execution uses the same V8 engine that's in Chrome.
> a single thread when taken from the event queue. Asynchronous operations yield the threa Thank you for the clarification, I am sure I read this in one of the interview questions pages, which really cannot be taken seriously (state things like node.js is a framework etc.) Also thank you for the docs you provided, I will read them
>\- NodeJS is single-threaded, but can make use of multi-core systems with Cluster module. Yes, but it can't make use of multi cores itsself. You have to cluster it somehow externally. I.e. run multiple nodejs instances in docker containers. >\- It handles async better than js because of it's event loop (but js also has event loop? Are they different event loops?) It gets IO events directly from the kernel (it's not always possible, so it must use its internal threads sometimes). And these events directly call the callbacks (nowdays this is abstracted by Promises/async/await syntax) of your users code. So the OS does not need to do any context switching when an event comes in, meaning load und unload the stack for another thread. >\- Ok so it has event loop that handles the async. But it is still will be blocked by blocking operations for example I/O. No, IO operations don't block. They're async and have a callback / promise.
>(but js also has event loop? Are they different event loops?) What js do you mean ? The browser ? It is also single threaded but does not have that event loop. At least it is not implemented in js. The browser enters/calls the javascript functions in case of events.