Эволюция интерфейса ВКонтакте: от ручного DOM и AJAX к архитектуре на React

От AJAX до React: как ВКонтакте перестроила фронтенд

Для команд, которые годами наращивают интерфейс поверх старого приложения, здесь важен не сам выбор библиотеки, а цена разрозненных способов рендера, сборки и релизов.

Когда фронтенд стал частью бэкенд-релиза

Веб-версии ВКонтакте в 2026 году исполнилось 20 лет. В статье Смирнов описывает исходную проблему: код фронтенда и бэкенда жил в одной кодовой базе и выпускался общим релизом. Изменение интерфейса могло затронуть серверную часть, а разработчикам приходилось работать с чужими для них архитектурами.

Мобильная и десктопная версии тоже разошлись. По словам автора материала, до 2021 года мобильную веб-версию поддерживали в том числе ради старых браузеров, включая Opera Mini и Windows Phone 7. Общий репозиторий не означал общего опыта разработки: переход между продуктами был сложным, а иногда требовал выделенного разработчика.

Проблема была не в одном устаревшем компоненте. В компании одновременно использовали четыре способа рендера компонентов, три способа отрисовки иконок и три варианта модальных окон. Похожие элементы могли выглядеть и работать сходно, но оставались несовместимыми. Это тот случай, когда очередной костыль не упрощает систему, а добавляет ещё один маршрут через неё.

React поверх старого транспорта

В качестве основы выбрали React. Решение опиралось на уже существующий опыт компании с VKUI, публичной библиотекой интерфейсов на React, которую развивали с 2017 года. Переписывать сайт одним большим релизом было нельзя: продуктовая разработка продолжалась, поэтому переход шёл итеративно.

На раннем этапе команда использовала подход, похожий на React Islands, поверх существующей AJAX-навигации. Сайт перехватывал переходы по ссылкам и отправлял запросы на бэкенд через XHR или Fetch. Ответ содержал необходимые данные, а React-страница или виджет подключались через root-элемент, подготовленный для рендера.

В этой схеме сервер передавал скрипт, который запускал рендер через eval. Это не универсальный рецепт миграции и не повод копировать решение вслепую. Важнее сама последовательность: команда не стала сразу ломать транспорт и заменять весь фронтенд, а встроила новый способ рендера в работающую систему. Детали дальнейших этапов в доступном описании ограничены, поэтому оценивать итоговую архитектуру по одному фрагменту нельзя.

Что проверить в собственном проекте

Практический вывод для команды простой: сначала составить инвентаризацию, потом выбирать очередной фреймворк. Сколько в проекте способов рендера одного и того же компонента? Можно ли обновить интерфейс без общего релиза с бэкендом? Совпадают ли сборка и правила подключения компонентов между продуктами? Если ответы расползаются по разным командам, миграция начинается не с React, а с фиксации границ и зависимостей.

Полезно отдельно проверить путь отката. В описанной Смирновым старой схеме фронтенд-изменение могло откатить и бэкенд-код из того же релиза. Развязать такие циклы выпуска обычно важнее, чем заменить одну библиотеку другой. Для ориентира по реакции на критические ситуации можно почитать материал об экстренной помощи при инсульте, хотя к архитектуре фронтенда он отношения не имеет.

git log --oneline
git diff --stat

Сначала выясните, что именно связано общим релизом. Потом меняйте границы. И да, бэкапы перед миграцией всё ещё дешевле героического восстановления прода.