DEV Community

Javascript is NOT single threaded!!

Roshan Kumar Badola on July 22, 2024

NO! you have not learned wrong that JavaScript is a single threaded language. It is a single-threaded language it has access to a single main threa...

Read full post

Red Ochsenbein (he/him) • Jul 23 '24

Do you have links to some sources? To my knowledge different environments are handling this differently. I think Chrome uses only one thread while Node takes advantage of libuv. So the whole point would not be if the language is single threaded, but if its implementation is.

Roshan Kumar Badola • Jul 23 '24

V8-Engine is used by chrome which does use libuv.

Red Ochsenbein (he/him) • Jul 23 '24 • Edited

V8 apparently does not use libuv.
github.com/nodejs/help/issues/3124

Roshan Kumar Badola • Jul 23 '24 • Edited

tech.jotform.com/unraveling-the-ja...
Well it can use it and yes chrome has it's own event loop as well.

Red Ochsenbein (he/him) • Jul 23 '24

Yes, that's what Node does, but - as it seems - not Chrome. That's why I'm asking for sources

Roshan Kumar Badola • Jul 23 '24 • Edited

This is one of the resource that I used other resource would be YouTube and Node.js docs.

Eckehard • Jul 23 '24

Don´t get me wrong, it is good to have more background information about how things work. But I was wondering, if this has any practical effect?

When a browser reads a page, it evaluates the content from top to bottom. Unless you do not add any infinite loops in Javascript, the evaluation of a page is finished within some milliseconds. HTML and JS are evaluated in the order they appear, but any code that has a long term effect (like events, setInterval, setTimeout etc...) are sorted out and forwarded to the event loop. So, in most cases it should not matter if the event loop runs in a separate thread or not.

Roshan Kumar Badola • Jul 23 '24

You see it is as you say. The code gets executed within milliseconds but "any code that has a long term effect (like events, setInterval, setTimeout etc...)" this part is what runs on separate background threads. See the main thread does not handle setinterval, it is passed to the browser to be taken care of in background. When you make a async fetch request the dom does not stop responding, because the fetch request itself is being handle by browser and dom is being handled by the main thread. When I say background threads I am talking about this process happening. Hope it clears your doubt.

Roshan Kumar Badola • Jul 23 '24

And again it has to do with the working of JavaScript, Node, Browsers, OS and every other component that makes a computer run, so it can get confusing very quickly. Especially when you learn about multithreading, multiprocessing, parallel and concurrent execution in Node.js.

Eckehard • Jul 23 '24 • Edited

Sure, in practice using different threads, makes things easier. Assume you have an inifinite loop in your script.

But my question was: Does this have any practical effect? After the main thread is finished it should not make any difference if the event loop was handeled by a separate thread or not.

And - by the way: even if the event loop runs in a different thread, this is still a single thread. So, it might not be blocked by the main thread, but if you put you infinite loop in an event, this will still block the whole site:

function test(){ 
  console.log("test is logged") 
  while(true): // infinite loop
}
setInterval(test,1000)

Roshan Kumar Badola • Jul 23 '24

Well with infinite loops any system will get blocked because of deadlock. And in reality yes it does not matter normally, but when you are making applications using Node.js any other program or language for example slack, discord or a game. You need to look out for these things as when your application is going to make use of system resources, you would not want your program to use all the resources all by itself. Multi-threading and multi-processing give us this exact ability and knowing about the single threaded nature of JavaScript helps with that.

Roshan Kumar Badola • Jul 23 '24 • Edited

And what you are talking about is concurrency in a single thread. With the kind of powerful systems we have running tasks concurrently even when we have a single threads gives the illusion of fast parallel programming and makes it look like there is no need to worry about having multiple threads.
The way we achieve concurrency is by dumping async code onto background threads and letting the main thread execute without waiting for the results to come.