React провернул трюк на миллиард долларов. Он превратил невозможную задачу O(n³) в O(n).

Сама задача такая. Ты обновляешь UI. У React есть две виртуальные DOM-деревья: одно отражает то, что сейчас на экране, второе то, что должно быть на экране. Нужно понять, что изменилось.

Классическое решение? Сравнить каждый узел дерева A с каждым узлом дерева B, чтобы найти оптимальное преобразование. Это алгоритм вычисления расстояния между деревьями. Его сложность O(n³).

Для 1000 элементов UI это миллиард сравнений. Приложение зависает на 10 секунд каждый раз, когда ты нажимаешь кнопку. Лента Facebook? Таймлайн Instagram? Нереально.

React посмотрел на эту классическую CS-задачу и решил: а что если нам не нужен идеальный результат? Что если достаточно «достаточно хорошего»?

Они сделали два жестких компромисса.

Компромисс 1. Разные типы компонентов? Даже не сравниваем их детей. Старое поддерево выкидываем целиком. Новое создаем целиком. Ноль анализа. Мгновенное O(1) решение. Иногда расточительно? Да. Быстро? Да.

Компромисс 2. Один и тот же тип? Сравниваем только узлы на одном уровне дерева. Не ищем более удачные соответствия где-то глубже. Какие-то оптимизации теряются? Конечно. Но сложность падает с O(n³) до O(n).

В итоге миллиард операций превращается в тысячу. 10 секунд превращаются в 2 миллисекунды. Невозможное становится тривиальным.

Поэтому ленты Instagram листаются плавно. Поэтому Facebook не зависает, когда ты ставишь лайк. Поэтому твое React-приложение с 10 000 компонентов ощущается мгновенным. Поэтому веб ощущается почти нативным.

React не решил невозможную задачу. Он просто сменил задачу.

Главный вывод: стремление к идеалу убивает скорость. А скорость — единственное, что действительно важно пользователю.

@WebDev_Plus