Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «Чому Web Worker не має доступу до DOM?». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

## Що таке DOM з точки зору потоків

**DOM (Document Object Model)** - це величезне дерево об'єктів,
яке браузер зберігає в пам'яті і синхронно пов'язує з візуальним відображенням сторінки (layout + render).

Коли JavaScript щось змінює в DOM (`element.textContent`, `style`, `appendChild` тощо):

- браузер **одразу** оновлює внутрішні структури,
- **перебудовує layout**,
- **перемальовує** елементи на екрані.

І все це - в **основному (UI) потоці** браузера.

---

## Як влаштований браузер "під капотом"

Спрощена схема:

```javascript
┌────────────────────┐
│ Main thread (UI)   │
│  ├─ JS Engine       │ ← доступ до DOM
│  ├─ Render Tree     │ ← відповідає за відображення
│  └─ Event Loop      │
└────────────────────┘
          │
          ▼
┌────────────────────┐
│ Web Worker Thread  │
│  └─ JS Engine       │ ← немає DOM, немає window/document
└────────────────────┘
```

DOM і Render Tree знаходяться **тільки в головному потоці**.
Усі Web Workers - ізольовані потоки, у них **своя копія JS-рушія**,
але **немає зв'язку з рендерером сторінки**.

---

## Чому не можна дати воркерам доступ до DOM

### 1. Проблема потокобезпеки

DOM не розроблений для одночасного доступу з декількох потоків.

> Якщо два потоки почнуть одночасно змінювати один і той самий елемент,
> можуть виникнути **гонки даних** (race conditions) і **краші** браузера.

JS однопотоковий не випадково: це робить DOM-операції **детермінованими** і безпечними.

---

### 2. UI-рендеринг не можна "розпаралелити"

Зміна DOM = зміна інтерфейсу.
Браузеру потрібно:

- перерахувати стилі (CSSOM),
- перебудувати layout,
- оновити шари рендеру (paint/composite).

Ці операції мають відбуватися **в чітко визначеному порядку**.
Якщо кілька потоків будуть змінювати DOM одночасно,
браузеру довелося б "синхронізувати" всі потоки - це вб'є продуктивність.

---

### 3. Безпека (isolation sandbox)

Web Workers ізольовані в окремій **пісочниці**:

- не бачать `window`, `document`, `localStorage`;
- не мають доступу до `alert()`, `confirm()`, `prompt()`;
- не можуть напряму читати/змінювати вміст сторінки.

Це захищає сайт від випадкової (чи шкідливої) зміни інтерфейсу і даних користувача.

---

### 4. Модель взаємодії через повідомлення

Замість прямого доступу до DOM, воркери спілкуються з основним потоком **через** `postMessage()`:

```javascript
// main.js
const worker = new Worker('worker.js');
worker.postMessage('Порахуй щось');
worker.onmessage = (e) => {
  document.querySelector('#result').textContent = e.data;
};
```

```javascript
// worker.js
onmessage = (e) => {
  const result = heavyCalculation();
  postMessage(result);
};
```

Таким чином:

- воркер робить обчислення -> надсилає результат ->
- головний потік оновлює DOM, якщо потрібно.

---

### 5. Продуктивність і передбачуваність

Якби воркер мав доступ до DOM:

- кожна зміна вимагала б синхронізації між потоками;
- браузеру довелося б **блокувати основний потік** для захисту даних;
- Event Loop став би непередбачуваним.

Тобто воркери **існують саме для того**, щоб *розвантажити* UI,
а не щоб втручатися в нього напряму.

---

## Що воркер *може* робити замість DOM

Воркери не рендерять інтерфейс, але можуть:

- рахувати, парсити, фільтрувати великі дані;
- працювати з `fetch`, `WebSocket`, `IndexedDB`;
- виконувати ML / криптографію;
- обробляти зображення, файли, аудіо;
- синхронізувати дані з сервером.

Все це - **без заморожування інтерфейсу**.

---

## Але все ж: як оновити DOM через воркер?

Через **повідомлення**:

```javascript
// worker.js
onmessage = () => {
  postMessage({ type: 'updateUI', text: 'Дані готові!' });
};
```

```javascript
// main.js
worker.onmessage = (e) => {
  if (e.data.type === 'updateUI') {
    document.querySelector('#status').textContent = e.data.text;
  }
};
```

Воркер "говорить", що робити,
а UI-потік вже **сам** вносить зміни в DOM.

---

## Проста аналогія

> Уяви, що головний потік - це **хірург**,
> а Web Worker - **асистент у лабораторії**.
>
> Асистент може рахувати, аналізувати, готувати дані,
> але **не може напряму торкатися пацієнта (DOM)**.
>
> Він просто передає результати хірургу,
> а той вже акуратно вносить зміни.

---

## Підсумок

| Питання | Відповідь |
|---|---|
| Чому воркер не має доступу до DOM? | Тому що DOM не потокобезпечний і пов'язаний з UI |
| Де знаходиться DOM? | Тільки в основному потоці браузера |
| Що робить воркер? | Обчислення, обробка даних, запити |
| Як спілкуватися з головним потоком? | Через `postMessage` / `onmessage` |
| Хто оновлює DOM? | Тільки основний потік |

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати652 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.