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

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

В октябре прошлого года я написал текст под названием «будут ли разработчики заботиться о фреймворках в будущем?», где предсказал, что LLM скроют от нас выбор фреймворка. Я ошибался — или, по крайней мере, ошибся со сроками.

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

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

По данным builtwith.com, за последние 12 месяцев было развернуто более 13 миллионов сайтов вне топ-1 млн, использующих React. Посмотрите на эти кривые:

Однако если посмотреть на HTTP Archive, картина выходит совсем другой. Использование React застыло на отметке 1,2 миллиона мобильных origin-узлов против 55 миллионов origin-узлов, о которых говорит Builtwith.

Размеры наборов данных несопоставимы. HTTP Archive охватывает примерно 12–16 миллионов origin-узлов, тогда как Builtwith, по их заявлениям, рассматривает около 414 миллионов корневых доменов. Кроме того, сайты попадают в HTTP Archive только при наличии какой-то активности, а многие сайты в Builtwith могут быть "припаркованными" доменами или ресурсами, которые фактически не используются.

Если смотреть на топ-1 млн, показатели сходятся сильнее: 140 тысяч против 160 тысяч.

Мы видим примерно 12–18% сайтов в топ-1 млн. Воспринимайте все эти цифры с поправкой на погрешность. Детект может работать некорректно, наборы данных отличаются по размеру, а определения того, что именно измеряется, могут не совпадать. Но тренды ощущаются однозначно: рост React продолжается, тогда как конкуренты вроде Angular, увы, топчутся на месте.

Так что же стало причиной резкого увеличения числа сайтов на React? Судя по данным, за последние 12–18 месяцев инструменты на базе LLM чаще всего предпочитают генерировать именно React-код.

Посмотрите на рост количества токенов на OpenRouter. Инструменты для разработки сжигают миллиарды токенов в день. Кривые выглядят схожими:

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

Модели и инструменты отдают предпочтение тем средствам, которыми уже пользуются разработчики, и это запускает самоподдерживающийся цикл распространения. Если вы сегодня запускаете новый API или инструмент, вам нужно учитывать, как экосистема его примет и как он попадёт в обучающий корпус LLM.

Здесь работают два контура обратной связи:

1.

• React доминирует в существующей сети (~13+ млн новых сайтов за 12 месяцев)

• LLM обучаются на существующей сети

• LLM по умолчанию генерируют React

• Новые сайты, созданные с помощью LLM, используют React

• Появляется ещё больше React-сайтов для будущего обучения

• Переходим ко второму шагу

2.

• React доминирует в экосистеме разработчиков

• IDE и инструменты, которые выбирают разработчики, по умолчанию выводят React

• Инструменты просят LLM генерировать React по умолчанию

• Новые сайты создаются на React

• Появляется ещё больше React-сайтов, что усиливает спрос на инструменты, генерирующие React

• Переходим к первому шагу

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

• Ваш фреймворк отсутствует в обучающих данных, потому что он новый

• Создатели инструментов жёстко прописывают React, потому что разработчики сегодня знают именно его

• Разработчики ожидают React, потому что он «просто работает»

• Компании не будут использовать ваш фреймворк, если их разработчики не смогут его поддерживать

• У React тысячи библиотек, а у вас — десятки

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

1. Попасть в обучающие данные LLM (минимум 12–18 месяцев задержки)

2. Убедить создателей инструментов изменить системные промпты (для этого уже нужна база пользователей)

3. Построить полноценную экосистему библиотек (годы работы)

4. Преодолеть инерцию и убедить разработчиков просить именно ваш инструмент

К тому моменту, когда вы выполните шаг 1, экосистема на React уже создаст ещё 10+ млн сайтов. Можно попробовать поменять порядок и провести мощную кампанию для закрепления в сознании разработчиков, дополнив её платными интеграциями в экосистему библиотек. Мы даже можем увидеть новые бизнес-модели, где авторы фреймворков и библиотек платят поставщикам инструментов за включение своих решений в системные промпты. Но даже в этом случае вам придётся бороться с устоявшимися паттернами как в мире React-библиотек, так и в обучающих данных LLM.

Речь здесь не о том, что React — лучший инструмент или что его модель чем-то особенно удобна для LLM (я совсем не вижу этому подтверждений). Важно другое: React перешёл ту точку, после которой сетевые эффекты делают жизнеспособные альтернативы практически невозможными.

Вот что окончательно меня убедило. На прошлой неделе я использовал Claude, чтобы собрать расширение для Chrome с помощью встроенного в Chrome prompt API. Claude послушно написал расширение целиком — но использовал self.ai.languageModel, API полугодичной давности. А актуальный API — LanguageModel.create(), но его просто не было в обучающем корпусе.

Добавьте сюда тот факт, что годы работы по Interop требуются, чтобы довести фичу до состояния «Baseline newly-available», и ещё примерно 30 месяцев — чтобы она стала «Baseline widely-available». К тому моменту экосистема уже уходит вперёд, и новая фича вынуждена конкурировать с давно устоявшимися паттернами как в мире React-библиотек, так и в обучающих данных LLM.

Это новая реальность: если чего-то нет в обучающих данных LLM, значит, его не существует. По крайней мере, 12–18 месяцев — до следующего цикла обучения модели, и до появления достаточного числа примеров в реальном мире, чтобы они статистически начали иметь значение.

Теперь применим это к фреймворкам:

• API веб-платформы: 0–6 месяцев реального использования до дедлайна обучения

• Новые фреймворки: 0–6 месяцев реального использования до дедлайна обучения

• Паттерны React: 10+ лет накопленных примеров

Сегодня, если вашего фреймворка или документации нет в обучающем корпусе LLM, он просто не будет появляться в ответах. Если в системном промпте инструмента, которым пользуется разработчик, нет вашего API, библиотеки или фреймворка — его не будет на выходе. И если пользователь инструмента не попросит явно использовать определённый API, библиотеку или фреймворк — его тоже не будет. Поставщики моделей фактически смещают предпочтения модели к определённому стилю, фреймворку или библиотеке.

Та же динамика распространяется на новые API веб-платформы, созданные как замена возможностям фреймворков. Типичный сценарий:

• Команды браузеров выявляют распространённый паттерн во фреймворках (например, CSS Nesting вместо Sass)

• Начинается многолетний процесс стандартизации

• Возможность появляется в браузерах

• Разработчики… продолжают использовать фреймворковый паттерн

Почему?

• LLM изучила старый паттерн: у Sass 15 лет примеров, у CSS Nesting — 1–2 года

• Фреймворк уже работает: разработчики на React используют styled-components, Tailwind, CSS-modules

• Экосистема сложилась: тысячи библиотек React используют существующие CSS-паттерны

• Нет стимула переходить: новая возможность платформы не делает сайт лучше для пользователя

Например:

• Sass всем нравился, но требует сборочного шага — поэтому появился CSS Nesting. Однако модели почти не генерируют его, потому что в корпусе гораздо больше примеров препроцессоров, а разработчики на React и так используют CSS-in-JS, которые LLM умеют воспроизводить.

• Карусели сложно собрать вручную, поэтому логично было бы сделать их частью платформы. Но уже есть огромное количество библиотек, которые создают отличные карусели и давно присутствуют в обучающих данных LLM.

Как автор множества сайтов, мне очень нравятся эти новые возможности. Один только CSS Nesting позволяет структурировать стили так, как мне проще читать и поддерживать. Но это никак не влияет на качество взаимодействия пользователя с сайтом. Не улучшает производительность. Не повышает доступность. Это просто облегчает мне жизнь как разработчику.

Единственные новые возможности платформы, которые действительно имеют значение, — те, что нельзя реализовать в пользовательском пространстве, например:

• многостраничные переходы с анимацией (новые возможности навигации),

• WebGPU (принципиально новый доступ к вычислениям),

• WebAuthN и PassKeys (базовые примитивы безопасности).

Всё остальное вынуждено конкурировать с устоявшимися паттернами и в React-библиотеках, и в обучающих данных LLM.

Есть как минимум три аудитории, которых стоит учитывать:

1. «Голова» — крупные компании, создающие веб-продукты. Топ-1000 сайтов забирают львиную долю трафика и дохода, и мы почти не видим крупных технологических смен в диапазоне от топ-1000 до топ-1 млн. Это зрелые проекты с устоявшимися командами, а смена технологий сложна и не всегда даёт очевидную отдачу, кроме возможного роста скорости разработки. Они, скорее всего, уже используют инструменты на базе LLM, чтобы ускорять работу, но менять фреймворки или библиотеки будут крайне неохотно.

2. «Середина» — малые команды и отдельные разработчики. Следующие ~10 миллионов сайтов создаются небольшими командами или одиночками, которые будут полностью опираться на LLM при создании новых проектов. И если они явно не укажут что-то иное, инструменты будут генерировать дефолтный стек — то есть React.

3. «Длинный хвост». Это люди, которые формально не являются веб-разработчиками и используют инструменты вроде Loveable, Replit или вообще работают прямо через чат. Они могут никогда не открыть код. Какая им разница до новых API? Их задача — сделать сайт, который выполняет нужную функцию. И именно они обеспечивают масштабный рост платформы: у нас есть шанс привлечь на веб миллионы новых создателей.

Именно группы 2 и 3 толкают вперёд рост числа сайтов в сети — и они почти наверняка не знают о Passkeys, WebAuthn, Web Components, CSS Nesting, View Transitions или о любых других новых возможностях платформы. Им просто нужен сайт, который делает то, что должен.

Обычным людям, использующим веб, действительно всё равно, какие инструменты, фреймворки или библиотеки стоят под капотом. Их волнует только опыт взаимодействия со страницей: достаточно ли быстро она загружается? Насколько плавные взаимодействия? Делает ли сайт то, что им нужно?

Сегодня, если вы компания, которая ориентируется на разработчиков в любой из этих категорий (или создаёте LLM-инструмент, генерирующий код), то отказ от вывода React по умолчанию означает уменьшить свою потенциальную аудиторию — в то время как конкуренты удовлетворяют текущий спрос.

Теперь взглянем на рабочую модель современных LLM-инструментов, которые генерируют код и отражают ту экосистему, на которой они обучались. Это означает, что любой новый API, фреймворк или библиотека должен преодолеть огромный барьер, чтобы модель начала его генерировать. Тот факт, что новая возможность ещё не попала в обучающие данные и недостаточно распространена, чтобы её паттерны и идиомы закрепились в корпусе и, следовательно, в выводе модели, должен серьёзно волновать тех, кто создаёт новые возможности веб-платформы.

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

Мне очень нравится то, что команда Remix делает с Remix 3, и я буду внимательно следить за тем, как он будет принят и как LLM-модели смогут его подхватить — чтобы понять, оправдаются ли выводы этой статьи на практике. Мне было бы интересно увидеть, сколько времени понадобится LLM, чтобы начать генерировать Remix-код без явного запроса или без предоставления документации в контексте.

Для авторов фреймворков. Создать новый фреймворк — значит создать продукт, который LLM не будет генерировать минимум 12–18 месяцев, без экосистемы библиотек, незнакомый разработчикам и нежеланный для компаний. Вы конкурируете не с техническими достоинствами React — вы конкурируете с его статистическим доминированием в каждом обучающем корпусе LLM и с предпочтениями поставщиков инструментов, ориентированных на своих пользователей.

Для разработчиков веб-платформы. Возможности, улучшающие разработку (синтаксический сахар, удобные API), будут конкурировать с устоявшимися React-паттернами в обучающих данных LLM. Они не будут массово приняты. Сосредоточьтесь на фундаментальных возможностях, которые невозможно реализовать в пользовательском пространстве. Текущим возможностям, над которыми работают команды браузеров, стоит пройти жёсткую проверку: какую пользу они принесут пользователю, а не разработчику? В этом смысле многие возможности платформы — от Web Components до синтаксических улучшений — просто не понадобятся подавляющему большинству людей, которые будут строить сайты в ближайшие годы.

Для создателей инструментов (например, IDE). Если ваш инструмент не генерирует React по умолчанию, вы сокращаете свою потенциальную аудиторию. Конкуренты обслуживают текущий спрос. Вы не можете позволить себе принципиальность в отношении разнообразия фреймворков.

Теория мёртвых фреймворков вообще не о том, что фреймворки «умирают». Она о том, что новые фреймворки в современном мире оказываются «мёртвы при рождении», потому что React стал платформой (по крайней мере, до тех пор, пока людям нужно поддерживать код).

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

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

Но есть и оптимистичный взгляд. Если использование LLM продолжит расти, вендоры инструментов будут вынуждены конкурировать друг с другом внутри этой однородной экосистемы. Когда все по умолчанию генерируют React, нельзя выделиться выбором фреймворка — придётся конкурировать качеством вывода. Рыночные силы сместят фокус с удобства разработки на качество пользовательского опыта.

В любом сценарии нам нужно начинать соревнование за пользовательский результат. Мне действительно хочется увидеть Evals и Benchmarks, которые оценивают качество итогового опыта так же, как Core Web Vitals оценивали производительность. Когда инструменты соревнуются за пользователей, победят те, что генерируют заметно лучший пользовательский опыт. Это давление заставит всю экосистему оптимизироваться под пользователя, а не под разработчика.

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

А что до самой «сырой», базовой веб-платформы? Её фокус — фундаментально новые возможности: те, что нельзя создать в пользовательском пространстве, или те, что дают очевидную пользу пользователю, недостижимую библиотеками.

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

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