Почему отказались от хранения чего-либо в реальном DOM?

Отказ от хранения состояния в реальном DOM: эволюция frontend1 разработки

Отказ от хранения данных и состояния приложения непосредственно в DOM (Document Object Model) стал ключевым поворотным моментом в развитии frontend1-разработки. Этот переход обусловлен фундаментальными проблемами архитектуры, которые стали критичными с ростом сложности веб-приложений.

Основные причины отказа

1. Проблема "двустороннего биндинга" (two-way data binding) и хранения состояния

Ранние подходы (например, в jQuery или чистом JavaScript) часто подразумевали хранение состояния прямо в DOM-элементах через атрибуты data-p, классы или непосредственное чтение значений полей.

// Проблемный подход: состояние "живёт" в DOM
const userStatus = document.getElementById('status').getAttribute('data-active');
document.getElementById('status').setAttribute('data-active', 'false');

Недостатки:

• Неявность состояния: Трудно определить, где и в каком виде хранится текущее состояние приложения. Нужно постоянно "выспрашивать" DOM.
• Сложность отладки: При изменении состояния невозможно отследить историю изменений или понять, что вызвало конкретное обновление.
• Проблемы синхронизации: При нескольких точках, влияющих на одно состояние, возникают конфликты и рассогласованность.

2. Низкая производительность при манипуляциях

Прямые манипуляции с DOM для обновления состояния являются дорогой операцией.

// Каждое такое изменение вызывает рефлоу и репайнт браузера
for (let item of data) {
  const element = document.createElement('div');
  element.innerText = item.name; // Состояние в тексте узла
  container.appendChild(element);
}

При каждом изменении браузер вынужден пересчитывать стили (reflow) и перерисовывать части страницы (repaint). Частые обновления приводят к "тормозам" интерфейса.

3. Слабая предсказуемость и тестируемость

Приложение, состояние которого размазано по сотням DOM-узлов, становится непредсказуемым (unpredictable). Один и тот же UI может быть получен разными путями, что ломает принцип детерминированности. Такую логику практически невозможно покрыть модульными тестами без сложных эмуляций браузерного окружения.

Современная парадигма: декларативный подход и виртуальный DOM

Решение пришло с архитектурой, где DOM становится только функцией от состояния (view = f(state)). Сохраняется в памяти JavaScript в виде обычных объектов или в специализированных менеджерах состояния (Redux, MobX, Zustand).

// Пример подхода в React: состояние в компоненте, DOM - его отражение
function UserList() {
  // Состояние хранится здесь, а не в DOM
  const [users, setUsers] = useState([]);
  const [isActive, setIsActive] = useState(true);

  // UI декларативно описывается на основе состояния
  return (
    <div>
      {users.filter(u => u.active === isActive).map(user => (
        <UserCard key={user.id} data={user} /> // Данные передаются пропсами
      ))}
    </div>
  );
}

Роль виртуального DOM (Virtual DOM)

Библиотеки вроде React ввели концепцию виртуального DOM – легковесного JavaScript-представления реального DOM.

// Псевдокод виртуального DOM
const virtualDom = {
  type: 'div',
  props: { className: 'header' },
  children: [
    { type: 'h1', props: {}, children: ['Hello World'] }
  ]
};

Как это работает:

1. Состояние изменяется в JavaScript.
2. Создается новый виртуальный DOM на основе этого состояния.
3. Diffing-алгоритм сравнивает новый и предыдущий виртуальный DOM, вычисляя минимальный набор изменений (patch).
4. Этот патч синхронно применяется к реальному DOM.

Преимущества:

• Предсказуемость: Состояние – единственный источник истины (single source of truth).
• Производительность: Минимизация операций с реальным DOM за счет патчинга.
• Отладка: Возможность логирования состояния, использования DevTools (Redux DevTools, Vue Devtools).
• Тестируемость: Логику можно тестировать в изоляции, передавая обычные объекты состояния.
• Кроссплатформенность: Одна логика состояния может рендериться в DOM, на мобильных платформах (React Native) или даже в терминале.

Итог: разделение ответственности

Отказ от хранения чего-либо в реальном DOM – это следствие перехода от императивного стиля программирования ("как сделать") к декларативному ("что получить"). DOM стал результатом рендеринга, а не хранилищем. Это разделило ответственность:

• JavaScript/State Manager: Хранение, изменение и бизнес-логика состояния.
• Virtual DOM / Renderer: Вычисление оптимальных UI-изменений.
• Реальный DOM (Браузер): Финальная отрисовка и взаимодействие с пользователем.

Такой подход сделал возможным создание сложных SPA (Single Page Applications), сохраняя производительность, поддерживаемость и обеспечивая лучший опыт разработки.