Алекс Рассел, известный специалист в области веб-технологий и веб-стандартов, подробно объяснил, почему React безнадежно устарел и не годится для использования в новых проектах. Это очень объемная статья, так что проведу только самые важные тезисы.
Перегруженность устаревшими компонентами
React создавался для эпохи, когда Internet Explorer 6 еще надо было поддерживать. Его архитектура (например, система синтетических событий и жестко заданный список элементов) была сделана с учетом ограничений IE. Сейчас эти ограничения не актуальны, а React продолжает загружать тонну пакетов для поддержки IE.
Виртуальный DOM не так быстр, как считают фанаты React
React заявлял о высокой производительности благодаря виртуальному DOM, но эти заявления были опровергнуты еще в 2015 году. Виртуальный DOM добавляет лишнюю работу, которую другие современные фреймворки просто не делают, используя более легкие и эффективные подходы. Это приводит к
React требует сложных решений для устранения проблем, которые он же и создает
Многие проблемы React, например, «прыжки» макета или неоптимальные перерисовки интерфейса, вынуждают разработчиков использовать сложные и специфичные инструменты для их решения. Эти решения не нужны в других фреймворках, где таких проблем изначально нет.
Альтернативы легче, быстрее и эффективнее
Современные реактивные библиотеки, такие как Svelte, Solid.js или Astro, предлагают аналогичные возможности без больших нагрузок на систему и сложной отладки. Они меньше по размеру, быстрее работают и лучше вписываются в современные архитектуры.
Выбор React часто основывается на стереотипах, а не на реальных потребностях
Многие команды выбирают React из-за его популярности, не учитывая, что многие проекты, от простых сайтов и блогов до интернет-магазинов, могут быть разработаны быстрее и проще без SPA-архитектуры, которая создает излишнюю сложность и увеличивает время загрузки. К тому же, React избыточен для приложений, которым не нужны длинные пользовательские сессии и сложная интерактивность.
Архитектура React создает сложности с переносом
Если вы используете React, переход на другую платформу может стать серьезной проблемой из-за закрытости его экосистемы. Например, поддержка Web Components в React ограничена.
React замедляет все фреймворки, в которых используется
К примеру, производительность Next.js оставляет желать лучшего – и в основном из-за React:
- Next.js генерирует существенно больший объем JavaScript по сравнению с более легковесными статическими генераторами сайтов (как 11ty или Astro).
- Дефолтная конфигурация Next.js загружает большие объемы отложенного JavaScript, что замедляет первоначальную загрузку страницы.
- Лишний JavaScript конкурирует за пропускную способность с другими важными элементами сайта – рекламным контентом и динамическими данными.
- React затрудняет эффективное масштабирование приложений на Next.js.
Высокая (во всех смыслах) стоимость разработки
React требует больше ресурсов, как серверных, так и клиентских. Кроме того, зарплаты специалистов по React выше, что увеличивает затраты на проект. Компании, избегающие React, часто выигрывают за счет более низких затрат на инфраструктуру и зарплаты.
Реактивность может быть достигнута без React
Другие фреймворки и подходы, такие как SSR (серверный рендеринг) или CSR (рендеринг на стороне клиента), позволяют достигать реактивности без избыточного веса и излишней работы, присущих React. Например, Astro позволяет комбинировать статические сайты с реактивными компонентами только там, где это нужно.
React создает ложное чувство удобства
React позиционируется как удобный инструмент для разработчиков, но это удобство часто достигается ценой снижения производительности для конечного пользователя. Современные подходы, напротив, предлагают удобство без жертв в производительности.
React называют «стандартом индустрии», но это, в лучшем случае, утешительный миф
А в худшем – осознанное искажение реальности, которое умалчивает о многообразии стека инструментов, связанных с React. Ведь React – это не просто библиотека, а целый образ жизни с кучей выборов на каждом этапе. Какой тип компонентов использовать: функциональные или классовые? Какой язык и компилятор предпочесть – TypeScript или все же JavaScript? Какой менеджер пакетов – npm, Yarn, pnpm, Turbo? Какой сборщик – Webpack, esbuild, SWC, Rollup? А что с инструментами вроде Vite, Turbopack или Nx? Или, скажем, какой инструмент для управления состоянием выбрать – Redux, MobX, Apollo или что-то другое? И это еще до обсуждения плагинов для обработки CSS или дополнительных подходов, которые многие команды пробовали интегрировать, например, CSS-in-JS.
React Native – лучший способ создать медленное приложение (или ужасный сайт)
Многие крупные компании, которые ранее активно использовали React Native, теперь от него отказались, потому что на нем можно создать только две вещи:
- Медленное мобильное приложение, которое требует постоянной доработки и изощренной настройки.
- Неуклюжий сайт, так как React Native изначально не предназначен для веба и плохо справляется с этой задачей.
Какой альтернативный фреймворк вы считаете наиболее перспективным для замены React в 2025 году и почему?
Хоть React и считается инструментом олдов, я все равно хочу научиться разрабатывать на нем
Займись Frontend-разработкой с профи из Газпромбанка и Аэрофлота! Создавай реальные проекты – от нуля до готового интернет-магазина. Доступ к курсу у тебя навсегда, а выпускники зарабатывают от 98 000 рублей после трудоустройства!
Комментарии