Suggest an edit

Improve this article

Refine the answer for “Multithreading in JS?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

Short answer:

> JavaScript **was deliberately designed as a single-threaded language**,
> to be **simple, safe, and predictable** -
> especially in the browser, where it originally ran.

Now let's break this down in detail.

---

## 1. Historical reason

When JavaScript was created (in 1995 at Netscape),
it was needed for **managing pages** -
handling clicks, forms, animations, the DOM, and so on.

In the browser, everything revolves around one tree of elements - the **DOM**.
If two threads modified the DOM at the same time,
that would cause **data races**, **conflicts**, **unpredictable states**.

**So:**
JS was made **single-threaded**, to guarantee
that **only one thread** can change the DOM at any given moment.

---

## 2. Threads = complexity and risk

Multithreading is not free.
It creates problems that JavaScript wanted to avoid:

| Problem | What it is |
|---|---|
| **Race conditions** | when two threads read and write the same value at the same time |
| **Deadlocks** | threads "hang", waiting for each other |
| **Complex synchronization** | you have to manually manage locks, mutexes, and so on |

These problems are typical of languages like C++, Java, or Go.
JS, by contrast, needs to be **safe for beginners** and "free of surprises".

---

## 3. But JS still does several things "at once" - how?

JavaScript uses an **asynchronous model with the Event Loop**,
not classic multithreading.

It **does not execute code in parallel**,
but **schedules tasks** and processes them "one after another" -
very quickly, creating the illusion of parallelism.

This is implemented via:

- the **Call Stack** - where code executes;
- the **Event Loop** - which decides when to pick up the next task;
- **Web APIs** - which run long operations (timers, fetch, and so on) outside the main thread.

---

## 4. What if you actually need parallelism?

It **is possible**, but **in a limited and safe way** - via **Web Workers** (in the browser)
or **Worker Threads** (in Node.js).

```javascript
// main.js
const worker = new Worker('worker.js');

worker.postMessage('Hello!');

worker.onmessage = (event) => {
  console.log('Response from the worker:', event.data);
};
```

```javascript
// worker.js
onmessage = (event) => {
  console.log('Main thread said:', event.data);
  postMessage('Hello back!');
};
```

Web Workers run **in separate threads**,
but they **have no access to the DOM** or **shared memory**.
They communicate with the main thread only through **message passing**.

> This is a safe way to get "multithreading without data races".

---

## 5. In Node.js - the same idea

Node.js is also **single-threaded** from JavaScript's point of view,
but under the hood (via libuv) there is a **thread pool**,
which runs low-level tasks (I/O, DNS, crypto, and so on) asynchronously.

So the JS code stays single-threaded,
while the system underneath **uses multithreading transparently**.

---

## 6. Why keep it single-threaded

| Reason | Explanation |
|---|---|
| **Simplicity** | The developer doesn't need to think about thread synchronization |
| **Safety** | Data races in the DOM are ruled out |
| **Predictability** | Code executes sequentially |
| **Asynchrony solves 90% of tasks** | Through the event loop you can handle thousands of requests "at once" |

---

## 7. When is real multithreading actually needed?

When you have **CPU-intensive computations** (for example, ML, encryption, image processing).
Then you can use:

- Web Workers (in the browser)
- Worker Threads (in Node.js)
- WebAssembly (for heavy computations)

---

## SUMMARY

| Question | Answer |
|---|---|
| Why is JS single-threaded? | To avoid conflicts when working with the DOM and to make the language safe |
| What replaces threads? | Asynchrony through the Event Loop |
| Can code run in parallel? | Yes, via Web Workers / Worker Threads |
| Why not "just use threads"? | Because multithreading would complicate the language and make it unsafe |

Markdown · drag & drop images · ⌘B / ⌘I shortcuts640 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.