За последние пару лет я провёл сотни технических собеседований — от junior до senior специалистов. И я обнаружил что есть одна тема, с пониманием которой есть проблемы почти у всех кандидатов с кем мне доводилось общаться. Это Virtual DOM.

Почти каждый кандидат объясняет его примерно так:

“Virtual DOM нужен, чтобы обновлять не всю страницу, а только её часть. Поэтому всё работает быстрее.”

Формулировка вроде звучит логично. Но проблема в том, что это неверное понимание в принципе.

Браузер и без всякого Virtual DOM не перерисовывает «всю страницу» при каждом изменении. Он обновляет только затронутые участки. Да и в целом невозможно повлиять на flow работы браузерного движка взаимодействуя с DOM через Virtual DOM.

Значит, дело не в этом.

Чтобы понять Virtual DOM по-настоящему, нужно выйти из плоскости “как сделать быстрее” и перейти в плоскость “как управлять системой”.

Два мира внутри браузера

В браузере есть два разных мира:

  1. JavaScript-движок

  2. Rendering Engine (DOM, layout, paint и т.д.)

DOM — это не "обычный объект" в JavaScript. Это интерфейс к внутренней системе браузера.

Когда вы пишете:

element.textContent = 'Hello'

Вы:

  • пересекаете границу JS → браузер,

  • модифицируете DOM-дерево,

  • потенциально запускаете пересчёт стилей,

  • возможно инициируете relayout,

  • возможно запускаете repaint.

Да, современные браузеры хорошо оптимизированы и они не перерисовывают всю страницу целиком при любом мельчайшем изменении, но взаимодействие с DOM — это host-операции и они всегда дороже, нежели чем операции внутри JS. Дороже - значит медленнее.

Настоящая проблема: DOM как часть логики

Теперь представьте приложение без Virtual DOM.

У вас есть:

  • состояние пользователя

  • список задач

  • фильтры

  • загрузка

  • ошибки

  • асинхронные запросы

Всё это нужно синхронизировать с интерфейсом.

В качестве примера возьмем простенькую реализацию с манипуляциями состояния кнопки:

function updateButton() {
  if (isDisabled) {   
    button.classList.add('disabled')  
    button.setAttribute('disabled', '')  
  } else {  
    button.classList.remove('disabled') 
    button.removeAttribute('disabled')  
  } 
  
  if (isLoading) { 
    button.classList.add('loading')  
    spinner.style.display = 'block'  
  } else { 
    button.classList.remove('loading')
    spinner.style.display = 'none'  
  }  
  
  if (hasError) { 
    button.classList.add('error')  
  } else {  
    button.classList.remove('error') 
  }
}

Пока состояний мало — всё управляемо.

Но теперь представьте:

  • isLoading приходит из одного запроса,

  • isDisabled из другого,

  • hasError меняется асинхронно,

  • а isActive обновляется через WebSocket.

DOM становится:

  • местом, где хранится промежуточное состояние,

  • объектом, с которым нужно синхронизироваться вручную,

  • источником потенциальной рассинхронизации.

Вот где начинается настоящая проблема.

Когда DOM становится источником истины

Без абстракции получается двусторонняя связь:

State ↔ DOM

Вы:

  • меняете состояние,

  • обновляете DOM,

  • иногда читаете DOM,

  • принимаете решения на основе DOM.

Например:

if (button.classList.contains('active')) { 
  // что-то делаем
}

DOM начинает участвовать в логике. А он для этого не предназначен.

Virtual DOM как архитектурный сдвиг

Virtual DOM — это попытка перенести управление интерфейсом полностью в JavaScript. Вместо того чтобы работать с DOM напрямую, мы создаём его модель:

{  
  type: 'button',
  props: {   
    class: isActive ? 'active' : '', 
    disabled: isDisabled  
  }, 
  children: isLoading ? 'Loading...' : 'Submit'
}

Это просто объект.

Он:

  • не вызывает перерасчетов layout,

  • не запускает repaint,

  • не имеет побочных эффектов.

Это просто данные.

Новый поток управления

С Virtual DOM архитектура становится односторонней:

State → Virtual DOM → Real DOM

Реальный DOM перестаёт быть активным участником логики. Он становится проекцией состояния. И это фундаментальное изменение.

Почему это важно для масштабирования

В маленьком проекте можно жить без абстракции, в большом — нет.

Когда приложение растёт:

  • состояний становится больше,

  • асинхронности больше,

  • компонентов больше,

  • зависимостей больше.

Без единой модели вы получаете хаос синхронизации. В то время как Virtual DOM позволяет четко разграничить состояние от визуализации:

DOM — это UI, отображающий текущее состояние.

Иными словами Virtual DOM дает нам архитектурные гарантии.

Что происходит при изменении состояния

Когда состояние меняется:

  1. Пересобирается виртуальное дерево.

  2. Оно сравнивается с предыдущим.

  3. Вычисляется разница.

  4. В DOM применяются только необходимые изменения.

Вся сложность:

  • вычисляется в JS,

  • сравнивается в JS,

  • планируется в JS.

То есть в браузер отправляется минимальный набор мутаций. Таким образом мы уменьшаем количество переходов из JS → DOM и получаем полный контроль над дорогими операциями и это самый важный момент. Так как в конечном итоге мы все равно заплатим цену за финальные изменения в UI, но ключевое тут "за финальные изменения".

Virtual DOM - это компромисс

Да, содержание и поддержание в актуальном состоянии Virtual DOM добавляет накладных расходов на:

  • создание объектов,

  • хранение предыдущего дерева,

  • diff-алгоритм,

  • patch.

Это дополнительная CPU-нагрузка. Но эта нагрузка происходит внутри JavaScript — в контролируемой и предсказуемой среде. Мы платим вычислениями за архитектурную стабильность.

Главное, что нужно понять

Virtual DOM — это не про “обновлять только часть страницы”.

Это про:

  • перенос контроля в JavaScript,

  • устранение ручной синхронизации,

  • минимизацию дорогостоящих host-операций,

  • превращение DOM в конечное устройство вывода.

Virtual DOM не делает браузер быстрее. Он делает систему управляемой.

Итог

Если формулировать точно:

Virtual DOM — это способ перестать управлять DOM напрямую и начать управлять данными, из которых DOM вычисляется. Это архитектурный слой между вашим кодом и браузером. И только после понимания этого имеет смысл говорить про diff, patch и оптимизации конкретных фреймворков.

Если вам интересна тема, то в следующей статье можно разобрать то, как именно Virtual DOM реализован во Vue 3 и насколько он уже оптимизирован на уровне runtime.