I agree. Multi-threading introduces a lot more complexity to your app than needed, so they should be used sparingly and only as the very last resort.
In fact, async I/O is what you need most of the time when you think that you need multi-threading. Consider that JavaScript on server side is so fast compared to traditional interpreters like PHP/Python only because of async I/O and it doesn't even need multi-threading!
Multi threading processing only introduces more complexity when you have mutable data.
async I/O does not solve problems which require multi threading to be solved, it solves an other problem which is made worse with multi threading. You need both; multi threading and async I/O.
Sometimes async I/O is not enough.
What about heavy CPU calculations? It'll block the main thread and make the application unresponsive. That's why Workers were introduced in Node 10.5.
Top comments (6)
I agree. Multi-threading introduces a lot more complexity to your app than needed, so they should be used sparingly and only as the very last resort.
In fact,
async I/Ois what you need most of the time when you think that you need multi-threading. Consider that JavaScript on server side is so fast compared to traditional interpreters like PHP/Python only because of async I/O and it doesn't even need multi-threading!Multi
threadingprocessing only introduces more complexity when you have mutable data.async I/O does not solve problems which require multi threading to be solved, it solves an other problem which is made worse with multi threading. You need both; multi threading and async I/O.
Real multithreading is much better than "clustering". You just need a borrow checker :v
Sometimes async I/O is not enough.
What about heavy CPU calculations? It'll block the main thread and make the application unresponsive. That's why
Workerswere introduced in Node 10.5.There is a solution for that. A React
useThreadhook.