Команда JavaScript for Devs подготовила перевод статьи о том, как доминирование React сдерживает развитие фронтенда. Автор утверждает: выбор React «по умолчанию» тормозит инновации, мешает развитию альтернативных фреймворков и превращает всю экосистему в монокультуру.

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

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

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

Тем временем фреймворки с настоящими инновациями пробиваются с трудом. Svelte полностью убирает накладные расходы фреймворка на этапе компиляции. Solid даёт тонкую реактивность без налога виртуального DOM. Qwik обеспечивает мгновенный старт благодаря подходу resumability. Эти подходы могут обгонять модель React в типовых сценариях, но их редко рассматривают всерьёз, потому что React выбирают "по умолчанию".

React по-прежнему отлично справляется со множеством задач. Проблема не в самом React, а в мышлении «React по умолчанию».

Предел инноваций

Технические основы React объясняют часть сегодняшних проблем. Виртуальный DOM был изящным решением для задач 2013 года, но, как отметил Рич Харрис в статье «Virtual DOM — это чистые накладные расходы», он создаёт работу, которую современные компиляторы часто могут избежать.

Hooks избавили нас от боли с классовыми компонентами, но привнесли новые сложности: массивы зависимостей, устаревающие замыкания (closures) и неправильное использование эффектов. Даже официальная документация React призывает к осторожности: «Возможно, вам не нужен эффект» (You Might Not Need an Effect). Server Components ускоряют время до получения первого байта, но добавляют архитектурную сложность и новые точки отказа.

React Compiler — умное решение, которое автоматизирует такие паттерны, как useMemo/useCallback. Но сам факт его существования — это сигнал: мы оптимизируемся вокруг ограничений, заложенных в модель React.

Сравните это с альтернативными подходами: Runes в Svelte 5 упрощают реактивность на этапе компиляции; тонкая реактивность Solid обновляет ровно то, что изменилось; resumability в Qwik избавляет от повторного запуска всего приложения на клиенте. Это не доработки модели React — это другие модели с другим пределом возможностей.

Инновации без принятия рынком ничего не меняют. А принятие невозможно, когда выбор делается на автомате.

Техдолг, который нам приходится расхлёбывать

Выбор React по умолчанию почти всегда влечёт за собой накладные расходы на рантайм и согласование (reconciliation) — и мы уже перестали это ставить под вопрос. Даже если React «достаточно быстрый», его предел ниже, чем у моделей с компиляцией или тонкой реактивностью. Время разработчиков уходит на управление повторными рендерами, зависимостями эффектов и границами повторного запуска приложения, вместо того чтобы создавать ценность для пользователя. Общий вывод из исследований производительности прост: JavaScript — одно из самых “тормозящих” мест на пути к быстрой загрузке страницы (The Cost of JavaScript).

Мы выстроили ментальные модели вокруг «React-паттернов», а не вокруг фундаментальных принципов веба. Такой подход снижает переносимость навыков и делает архитектурную инерцию почти неизбежной. Потери здесь — не только в производительности. Мы упускаем возможности, когда даже не рассматриваем более подходящие альтернативы. Например, бенчмарки вроде JS Framework Benchmark показывают, что такие фреймворки, как Solid, могут давать ускорение в 2–3 раза в сценариях с интенсивной реактивностью по сравнению с React.

Фреймворки, которые задыхаются

Svelte: революция в компиляции

Svelte переносит работу на этап компиляции: без виртуального DOM и с минимальным рантаймом. Компоненты превращаются в точечные операции над DOM. Ментальная модель ближе к базовым принципам веба.

Но аргумент «мало вакансий» искусственно сдерживает распространение Svelte, несмотря на его техническое превосходство в большинстве случаев. Реальные примеры, такие как переход The Guardian на Svelte во фронтенде, показывают измеримый рост производительности и продуктивности команд: сокращение размеров бандла и ускорение загрузки. Так, разработчик Шон Ван сократил размер своего сайта со 187 KB в React до всего 9 KB на Svelte благодаря компиляционным оптимизациям, которые убирают накладные расходы фреймворка с рантайма. Благодаря чему приложение стало быстрее и эффективнее, особенно с медленным интернет-соединением.

Solid: подход с реактивными примитивами

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

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

Qwik: инновация resumability

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

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

Все три фреймворка недооценены не из-за отсутствия достоинств, а потому что выбор «React по умолчанию» блокирует их использование.

Более того, API React заметно больше и сложнее, чем у альтернатив: хуки, контекст, редьюсеры, паттерны мемоизации — всё это требует тщательного контроля, чтобы не попасть в ловушки. Широкий набор API повышает когнитивную нагрузку на разработчиков и нередко приводит к багам из-за неверных зависимостей или чрезмерной инженерии. Например, во время сбоя Cloudflare 12 сентября 2025 года проблемный useEffect с некорректным массивом зависимостей вызвал повторные API-запросы, перегрузив Tenant Service и вызвав масштабные отказы. В отличие от этого, Svelte, Solid и Qwik предлагают меньшие и более сфокусированные API, опирающиеся на принципы веба, что снижает ментальную нагрузку и упрощает освоение и поддержку.

Тюрьма сетевого эффекта

Доминирование React создаёт самоподдерживающиеся барьеры. Компании ищут «React-разработчиков», а не «frontend-инженеров», что ограничивает разнообразие навыков. Библиотеки компонентов и привычки команд формируют институциональную инерцию.

Осторожные лиды выбирают «безопасный» вариант. Университеты учат тому, что требуют вакансии. Цикл продолжается, независимо от технических достоинств.

Это уже не здоровая конкуренция — это захват экосистемы.

Как разорвать сетевой эффект

Выбраться из этого можно только осознанными действиями на разных уровнях. Техлиды должны выбирать инструменты исходя из ограничений и достоинств, а не по инерции. Компании могут выделять небольшой бюджет на эксперименты с альтернативами. Разработчики — развивать навыки за пределами одной ментальной модели.

Преподаватели могут давать фреймворк-независимые концепции наряду с конкретными инструментами. Контрибьюторы Open source могут помогать альтернативным экосистемам созревать.

Перемены не произойдут сами. Нужен сознательный выбор.

Чек-лист для выбора фреймворка

Чтобы выбирать осознанно, пользуйтесь этим простым чек-листом при старте нового проекта:

• Оцените требования к производительности. Посмотрите на метрики вроде времени старта, эффективности обновлений и размера бандла. Если важна скорость, отдавайте приоритет фреймворкам с оптимизациями на этапе компиляции.

• Навыки команды и порог входа. Учитывайте текущий опыт команды, но не забывайте о путях миграции — многие альтернативы предлагают плавный переход (например, Solid совместим с JSX из React).

• Масштабируемость и стоимость поддержки. Считайте долгосрочные затраты: поддержку, управление зависимостями, техдолг. Альтернативы часто уменьшают нагрузку на рантайм, снижая стоимость хостинга и улучшают масштабируемость.

• Соответствие экосистеме. Балансируйте зрелость и инновации. Пилотируйте на некритичных участках, чтобы проверить, насколько реальна миграция и каков ROI.

Стандартные возражения

«Но экосистема же зрелая!» Зрелость важна, но она же закрепляет инерцию. Возраст фреймворка не всегда равен его пригодности под современные требования.

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

Меньшие экосистемы альтернативных фреймворков поощряют работу «от основ», формируют более глубокое понимание и уменьшают техдолг. А с появлением ИИ-ассистентов, способных быстро генерировать точечные функции под конкретные нужды, барьер для создания собственных утилит стал значительно ниже. Это делает реальным отказ от универсальных библиотек вроде lodash или Moment/date-fns в пользу лёгких и точных решений, написанных под конкретное приложение.

«Но как же найм!» Найм следует за спросом. Можно снизить риски, пилотируя альтернативы на некритичных участках, а потом нанимать специалистов с базовыми знаниями и обучать их на месте.

«Но библиотеки компонентов!» Фреймворк-независимые дизайн-системы и Web Components уменьшают привязку к стеку, сохраняя при этом скорость разработки.

«Но стабильность!» Эволюция React от классов к хукам и далее к Server Components показывает скорее постоянные изменения, чем стабильность. Альтернативные фреймворки часто предлагают более последовательные API.

«Но проверено масштабом!» jQuery тоже был проверен масштабом. Прошлый успех не гарантирует будущую актуальность.

Ущерб для экосистемы

Моно-культура тормозит развитие веба, когда ограничения одного фреймворка становятся де-факто пределами для всех. Разработчики тратят силы на решение проблем конкретного фреймворка, вместо того чтобы двигать платформу вперёд. Инвестиции идут к лидерам рынка, независимо от их технической состоятельности.

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

Вся экосистема страдает, когда исчезает разнообразие.

Сад, который мы могли бы вырастить

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

Ставка на единственную модель создаёт точку отказа. Что произойдёт, если она упрётся в жёсткий потолок? Какие возможности мы теряем, когда не пробуем альтернативы?

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

Хватит сажать одно и то же семя по привычке. Сад, который мы могли бы вырастить, исследуя разные фреймворки, был бы и устойчивее, и богаче на инновации, чем та монокультура, в которую мы скатились.

Выбор за нами.

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

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