Команда JavaScript for Devs подготовила перевод статьи о том, почему веб-команды застревают на орбите фреймворков и забывают о возможностях самой платформы. Автор убеждён: браузеры развиваются быстрее, чем экосистемы вокруг них, а зависимость от React и других инструментов тормозит инновации. Пора снова смотреть на веб как на платформу, а не как на “внутренность” фреймворка.

Фреймворки должны были избавить нас от грязной рутины веб-разработки. И какое-то время так и было — пока их собственная гравитация не начала затягивать в орбиту всё вокруг.

Каждый фреймворк приносил настоящий прогресс. React, Vue, Angular, Svelte и другие привнесли в фронтенд структуру, модульность и предсказуемость. Но теперь, после десятилетия господства React, произошло нечто другое. Мы не просто писали приложения на React — мы выстроили вокруг него целую экосистему: процессы найма, дизайн-системы, даже целые компании — всё завязано на его способ мышления.

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

Гравитация успеха

React уже давно не просто библиотека. Это полноценная экосистема, которая определяет, как фронтенд-разработчикам “полагается” мыслить.

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

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

Мы уже видели этот цикл с jQuery, и видим его снова — теперь с React. Увидим и с тем, что придёт после него. Успех порождает стандартизацию, стандартизация — инерцию, а инерция убеждает нас, что прогресс может подождать. Проблема — в шаблоне поведения, а не в конкретном фреймворке.

Но сегодня React — в самом центре этой динамики, и ставки куда выше, чем когда-то с jQuery. Целые продуктовые линии, архитектурные решения и карьерные траектории завязаны на React-образные допущения. Мы даже начали определять разработчиков по фреймворку: в вакансиях нередко ищут «React-разработчиков», а не фронтендеров. Даже ИИ-агенты по умолчанию стартуют новые фронтенд-проекты на React, если их специально не направить иначе.

Возможно, единственное, что труднее, чем строить на фреймворке, — признать, что иногда нужно строить без него.

Эволюция и инновации

Эволюция React прекрасно отражает это напряжение. Недавние вехи — создание React Foundation, выход React Compiler версии 1.0 и нововведения в React 19.2: компонент <Activity />, useEffectEvent, Performance Tracks в DevTools, а также экспериментальные <ViewTransition /> и Fragment Refs.

Все эти обновления — реальные улучшения. Особенно компилятор, который приносит автоматическую мемоизацию на этапе сборки, убирая необходимость вручную оптимизировать с помощью useMemo и useCallback. Боевые деплои показывают ощутимый прирост производительности: приложения в Meta Quest Store получили до 2.5x более быстрые отклики именно благодаря этому. Такие автоматические оптимизации — действительно ценная работа, которая двигает вперёд всю экосистему.

Но вот что важно: веб-платформа тихо развивалась в том же направлении уже много лет, внедряя многие возможности, за которыми фреймворки гонялись всё это время.

Браузеры уже поставляют View Transitions, Container Queries и более умные примитивы планирования работы. Платформа развивается вполне уверенно, но большинство команд не прикоснётся к этим возможностям, пока React официально не обернёт их в хук или пока они не появятся в документации Next.js.

Инновации продолжают происходить по всей экосистеме, но для многих они становятся «настоящими» только после того, как React подтвердит, что так можно. Что, конечно, удобно — если вам нравится ждать разрешения пользоваться платформой, на которой вы и так уже всё строите.

React Foundation и вопрос приоритетов

React Foundation — важная веха в вопросах управления и долгосрочной устойчивости. Новый фонд входит в состав Linux Foundation, а среди его учредителей — Meta, Vercel, Microsoft, Amazon, Expo, Callstack и Software Mansion.

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

Но это пока что не меняет фундаментальную динамику разработки фреймворка.

Инженеры, которые фактически создают React, по-прежнему работают в таких компаниях, как Meta и Vercel. Исследования ведутся на их уровне, под их требования к производительности. Дорожная карта отражает приоритеты компаний, которые финансируют разработку на полный рабочий день.

И надо признать: React работает в масштабах, с которыми подавляющее большинство фреймворков никогда не столкнётся. Meta обслуживает миллиарды пользователей через фронтенды, которые запускаются на слабых мобильных устройствах по всему миру, поэтому ей нужна производительность такого уровня, которая оправдывает наличие отдельных исследовательских команд. Инновации, которые они создают — оптимизация на уровне компилятора, конкурентный рендеринг, всё более детальная инструментализация производительности — решают реальные задачи, возникающие только на столь огромных масштабах.

Но эти приоритеты не обязательно совпадают с вашими приоритетами — и в этом весь конфликт. Инновации React формируются вокруг проблем компаний, работающих на масштабе «миллиарды пользователей», а не вокруг задач команд, которые создают продукты для тысяч или миллионов.

Сигналы в лаборатории: исследования на масштабе энтерпрайза

Внутренние исследования React показывают, что команда отлично осознаёт нынешние архитектурные ограничения. Экспериментальные проекты вроде Forest изучают ленивые вычислительные графы, похожие на сигналы — по сути, тонкозернистую реактивность вместо грубого механизма повторных ререндеров в React. Другой проект, Fir, исследует методы инкрементального рендеринга.

Это не пункты дорожной карты; это лишь исследовательские прототипы, создаваемые внутри Meta. Возможно, они никогда не выйдут в публичном виде. Но они показывают важную вещь: команда React понимает, что модель virtual DOM имеет свои пределы производительности, и активно ищет, что придёт ей на смену.

Это отличные исследования, но они снова демонстрируют ту же динамику: подобные эксперименты происходят за стенами Big Tech, в рамках сроков, определяемых корпоративными приоритетами и доступными ресурсами. Между тем фреймворки вроде Solid и Qwik уже несколько лет поставляют тонкозернистую реактивность в продакшене. Svelte 5 в 2024 году выпустил руны, фактически приведя сигналы в широкое употребление.

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

Что React сделал правильно

Я не хочу, чтобы эта критика умаляла то, чего React добился за последние двенадцать лет.

React популяризировал декларативные интерфейсы и сделал компонентную архитектуру мейнстримом — и само по себе это было огромным прорывом. Он доказал, что удобство разработки важно не меньше, чем производительность рантайма, и ввёл идею, что UI может быть чистой функцией от входных пропсов и состояния. Такой подход сделал сложные интерфейсы куда проще для понимания. Позднее хуки элегантно решили хаос с классовыми компонентами, а конкурентный рендеринг через <Suspense /> открыл путь к по-настоящему отзывчивым интерфейсам.

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

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

И что важно — переход на Solid, Svelte или Vue не устранил бы эту динамику; он лишь сместил бы её центр тяжести. Каждый фреймворк создаёт собственную орбиту инструментов, паттернов и зависимостей. Цель не в том, чтобы найти «правильный» фреймворк, а в том, чтобы строить приложения, достаточно устойчивые, чтобы пережить миграцию на любой фреймворк — включая те, которые ещё даже не придуманы.

Инерция и культурные ограничения

Эта инерция — не про лень, а про организацию процессов. Поменять стек — дорого и болезненно. Переучивать разработчиков, заново собирать библиотеки компонентов, перестраивать CI-пайплайны — всё это требует времени и денег, а отдача редко приходит сразу. Риски высокие, затраты большие, и объяснить необходимость таких перемен сложно. Поэтому большинство компаний остаются при своём — и честно говоря, их трудно в этом винить.

Но пока мы стоим на месте, платформа движется вперёд. Браузер умеет потоково загружать и выполнять повторную инициализацию приложения, нативно анимировать переходы, координировать рендеринг без всякого фреймворка. И всё же большинство команд не прикасаются к этим возможностям, пока они не окажутся встроенными или официально одобренными экосистемой.

Это ограничение не инженерное, а культурное. Мы каким-то образом пришли к тому, что «работает во всех браузерах» кажется рискованнее, чем «работает в нашем фреймворке».

Улучшение процессов управления тут не помогает. Проблема не в организационной структуре React, а в нашем отношении к нему. Слишком многие команды ждут, пока React упакует и благословит возможности платформы, прежде чем начать их использовать — даже если те уже доступны в браузерах сегодня.

Компонент <Activity />: формализация vs. инновации

Компонент <Activity /> в React 19.2 отлично иллюстрирует эту ситуацию. Он выступает границей, которая скрывает UI, сохраняя состояние компонента и размонтируя эффекты. В режиме mode="hidden" он приостанавливает подписки, таймеры и сетевые запросы, но оставляет нетронутыми значения форм и позицию прокрутки. Когда режим меняется на mode="visible", эффекты аккуратно монтируются заново.

Это действительно полезная возможность. Вкладки, модальные окна и прогрессивный рендеринг прекрасно выигрывают от такого поведения. Та же идея подходит для случаев, когда нужно заранее отрисовать что-то в фоне или сохранить состояние при переходах между видами. Компонент плавно интегрируется с жизненным циклом React и границами <Suspense />, позволяя выборочно выполнять повторную инициализацию приложения и использовать более умные стратегии рендеринга.

Но он также подчёркивает важную грань между формализацией и инновацией.

Суть не нова: всё сводится к тому, чтобы приостанавливать побочные эффекты, сохраняя состояние. Похожие вещи уже можно реализовать с помощью наблюдателей видимости, корректной очистки эффектов и аккуратных паттернов управления состоянием. Платформа сама предоставляет примитивы — такие как IntersectionObserver, механизмы сохранения DOM-состояния и ручной контроль эффектов.

То, что привносит <Activity />, — это формализация и координация с внутренними механизмами React. Его проще использовать, сложнее неправильно применить, и он естественно состыковывается с возможностями вроде <Suspense />. Но при этом он показывает, насколько зависимым стало наше мышление от фреймворков. Мы ждём, когда React формализует поведение платформы, вместо того чтобы воспользоваться тем, что уже доступно.

И это не критика самого <Activity />: это хорошо продуманный API, решающий реальную задачу. Просто он напоминает, что мы привыкли ждать решений от фреймворков, даже когда платформа уже позволяет решить проблему своими силами. Долго вращаясь на орбите React, мы почти забыли, как это — строить что-то вне его гравитации.

Мышление «сначала платформа»

Ответ не в том, чтобы отказаться от фреймворка, а в том, чтобы помнить: он работает внутри веб-платформы, а не наоборот. Я уже писал о подходе «строить веб островами» — как о способе заново открыть возможности платформы, которые у нас уже есть.

Даже оставаясь в рамках React, можно мыслить «сначала платформа»:

• Используйте нативные формы и отправку данных на сервер, а затем добавляйте клиентскую логику поверх.

• Предпочитайте семантический HTML и ARIA, прежде чем тянуться к библиотекам компонентов.

• Пробуйте View Transitions напрямую, с минимальными обёртками под React, не ожидая «официального» API.

• Используйте Web Components для изолированных виджетов, которые переживут миграцию на другой фреймворк.

• Держите бизнес-логику вне фреймворка — обычные TypeScript-модули вместо хуков; старайтесь, чтобы хуки оставались короткими за счёт вынесения логики наружу.

• Сначала профилируйте производительность в браузерных DevTools, а уже потом в React DevTools.

• Пробуйте нативные возможности CSS — :has(), @layer, scroll snap, @container, prefers-reduced-motion — прежде чем подключать JavaScript-решения.

• Используйте fetch, FormData и URLSearchParams вместо фреймворк-специфичных аналогов, где это возможно.

• Экспериментируйте с History API (pushState, popstate) напрямую, прежде чем переходить к React Router.

• Организуйте код так, чтобы роутинг, загрузка данных и управление состоянием могли заменяться независимо от React.

• Тестируйте поведение реальных браузерных API, а не только абстракции фреймворка.

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

Русскоязычное JavaScript сообщество

Друзья! Эту статью перевела команда «JavaScript for Devs» — сообщества, где мы делимся практическими кейсами, инструментами для разработчиков и свежими новостями из мира Frontend. Подписывайтесь, чтобы быть в курсе и ничего не упустить!