React vs Vue 3

Сравнение React и Vue 3 — это идеальный способ увидеть противостояние двух фундаментальных философий фронтенда: иммутабельности против реактивности на Proxy (мутабельности).

Посмотрите, насколько по-разному решается одна и та же задача.

React (Иммутабельный подход)

import { useState } from 'react';

function ReactCounter() {
  const [state, setState] = useState({ count: 0, user: { name: 'Алекс' } });

  const increment = () => {
    // Нельзя: state.count++
    // Нужно создавать копию ВСЕХ уровней вложенности
    setState({
      ...state,
      count: state.count + 1
    });
  };

  // При вызове setState этот компонент И ВСЕ ЕГО ДЕТИ запустят рендер
  return <button onClick={increment}>Счетчик: {state.count}</button>;
}

Vue 3 (Мутабельный подход на Proxy)

<script setup>
import { ref } from 'vue';

// ref() внутри использует JavaScript Proxy
const state = ref({ count: 0, user: { name: 'Алекс' } });

const increment = () => {
  // Прямая мутация! Vue сам перехватит это изменение
  state.value.count++; 
};
</script>

<template>
  <!-- Перерисуется ТОЛЬКО эта кнопка, дочерние компоненты не затронутся -->
  <button @click="increment">Счетчик: {{ state.count }}</button>
</template>

Архитектурная разница и производительность

1. Virtual DOM и его роль
   • В React: При любом изменении стейта React строит новое дерево Virtual DOM для компонента и его поддерева, а затем сравнивает его со старым (диффинг). Если дерево большое, это бьет по процессору.
   • Во Vue 3: Компилятор Vue анализирует HTML-шаблон во время сборки и разделяет его на динамические и статические части. Благодаря Proxy Vue точно знает, какая именно переменная изменилась, и обновляет Virtual DOM точечно, пропуская проверку статических элементов.
2. Проблема «лишних рендеров»
   • В React: Если вы передадите объект через props в дочерний компонент, и этот объект будет пересоздаваться при каждом рендере родителя (новая ссылка), дочерний компонент будет постоянно перерисовываться. Разработчику приходится расставлять useMemo и useCallback.
   • Во Vue 3: Такой проблемы нет. Компонент отслеживает только те свойства, которые реально выводятся в его <template>. Если вы передали объект, но дочерний компонент не использует изменившееся свойство, он не будет перерисовываться.

Что в итоге лучше?

• Vue 3 выигрывает в производительности «по умолчанию» для большинства стандартных приложений. Разработчику не нужно думать о мемоизации, ссылках и оптимизации рендеров — фреймворк делает это сам за счет реактивности.
• React из коробки дает полный контроль над потоком данных в ущерб производительности (но и это можно исправить некоторыми сторонними инструментами). Иммутабельность делает код более предсказуемым. Вы всегда точно знаете: если интерфейс изменился, значит, пришла новая ссылка. Это упрощает тестирование сложных систем и построение огромных enterprise-приложений, где хаотичные мутации из разных мест приложения могли бы превратить код в «спагетти».

Это сравнение полностью актуально для React 16, 17, 18 и современного React 19. Основа философии React — иммутабельность и сравнение объектов по ссылкам — остается неизменной на протяжении всех этих версий.

Историческое развитие и эволюция стейт-менеджмента

Ниже приведена хронологическая таблица, которая показывает, как развивался React и как менялись подходы к управлению состоянием от зарождения Flux до наших дней.

Для наглядности добавил параллельное историческое развитие Vue:

Почему иммутабельность — это «дух времени» 2014 года?

Иммутабельность в React была выбрана потому, что в 2013–2014 годах в браузерах не было технической возможности сделать мутабельность эффективной и безопасной (🍸):

1. Отсутствие Proxy: Объект Proxy появился в JavaScript (ES6) и стал поддерживаться браузерами только к 2015–2016 годам. Без Proxy отследить мутацию объекта можно было только «грязными хаками» (например, постоянным сканированием всех объектов по таймеру, как это делал старый AngularJS в своем digest cycle, что жутко тормозило).
2. Простота ссылок: Сравнить две ссылки в памяти (objA === objB) — это самая быстрая операция в JavaScript, которая поддерживалась всегда. Архитекторы React выбрали этот путь, так как он гарантировал максимальную скорость работы Virtual DOM на компьютерах того времени.

🍸 Под термином «безопасный» в контексте 2013–2014 годов инженеры Facebook понимали предсказуемость кода и защиту от человеческого фактора (багов разработчика), а не кибербезопасность. Иммутабельный подход считался концептуально безопасным по трем главным причинам:

1. Защита от «скрытых» побочных эффектов (Side Effects)

В мутабельном коде того времени (например, в AngularJS или Backbone) вы могли передать объект в дочерний компонент, и этот компонент мог случайно изменить свойство внутри объекта. Родительский компонент об этом не узнавал, другие дочерние компоненты, зависящие от этого объекта, вели себя непредсказуемо, а интерфейс «разваливался». Искать такой баг в огромном приложении было кошмаром. Иммутабельность давала безопасность: если компонент получает данные, он знает, что они гарантированно не изменятся за его спиной. Данные защищены от случайной перезаписи в любой другой точке программы.

2. Математическая предсказуемость (Pure Functions)

React изначально создавался фанатами функционального программирования. В этой концепции компонент — это «чистая функция».

Component(props, state) = UI

Если props и state неизменяемы, то при одних и тех же входных данных функция всегда вернет абсолютно одинаковый HTML. Это делало код «безопасным для тестирования»: вы могли легко предсказать, как будет выглядеть интерфейс, просто посмотрев на текущие данные, без необходимости прослеживать всю историю мутаций объекта в памяти.

3. Единственный источник правды (Single Source of Truth)

В архитектуре Flux (которая шла в комплекте с React) данные могли изменяться только в одном специальном месте — Хранилище (Store), и только строго определенным способом (через Actions). Компоненты не имели права ничего мутировать, они могли только «читать» данные и отправлять сигналы наверх. Это устраняло ситуацию, когда три разных компонента одновременно пытаются по-своему перезаписать один и тот же глобальный объект, создавая состояние гонки (race conditions).