Бенчмарк: сколько стоит нейросети-агенту писать на JS-фреймворках

Автор блога, недовольный тем, что решения во фронтенд-разработке принимаются «по ощущениям», написал бенчмарк для эпохи кодинг-агентов. Он отмечает, что фреймворки часто переписывают из-за того, что какой-то из них «лучше для агентов», а код якобы «быстрее» и агенты «меньше ошибаются», и всё это, по его словам, обычно без доказательств.

Устройство теста: небольшое, но нетривиальное приложение про покемонов на основе PokéAPI (список покемонов с типами, приёмами и данными из разных игр, есть поиск и фильтры). Агенту поручали собрать его на конкретном JavaScript-фреймворке или мета-фреймворке (Next.js, Nuxt, SvelteKit и др.), результат проверялся набором тестов на соответствие спецификации (чтобы агент не жульничал), а затем оценивался по времени разработки, потраченным токенам, числу строк кода и показателям производительности и доступности в Lighthouse. Тесты строились на дереве доступности, а не на «сыром» DOM, чтобы не навязывать HTML-структуру: один из фреймворков использует веб-компоненты с shadow DOM.

Условия выравнивали: каждому фреймворку разрешили официальный MCP или навыки (skills); архитектуру (SSR или CSR) и требование к быстродействию не задавали; Opus 5.5 с высоким уровнем усилий (high effort) получал спецификацию и указание взять последнюю версию фреймворка. Агент работал в песочнице, не знал о проверке Lighthouse, но имел набор conformance-тестов. Tailwind, Bootstrap и другие компонентные фреймворки были запрещены, внешний вид задавался набором токенов из спецификации. Автор оговаривается: эксперимент неидеален, приложение, это контентный сайт с малой интерактивностью, ближе к Википедии, чем к Figma или GMail; а все измерения «стохастичны».

Для каждого фреймворка брали медиану из 5 запусков. Исключение, Angular: в двух запусках агент собрал SSR-приложение, отвергавшее не-localhost-запросы (хотя в инструкции прямо говорилось про обратный прокси), поэтому для части метрик взяли 3 итерации; эти два сбоя автор счёл законным нарушением спецификации и не перезапускал. В разделе о стоимости учтены все 5 запусков Angular.

Стоимость. Цифры, это API-цены, которые показывает Claude Code, а не реальные траты: у автора тариф Max за $100 в месяц. Разброс велик: медиана React Router примерно на $1 хуже, чем у Hono+htmx, но самый дешёвый запуск React Router ($2,82) всё же дешевле самого дорогого запуска Hono+htmx ($3,19). Устойчивая закономерность, SvelteKit, Gracile+Lit и Angular дороже остальных. По мнению автора, для SvelteKit причина может быть в том, что агенты в каждом запуске читали руководство по миграции на SvelteKit v3 (вероятно, оно слишком новое для обучающих данных Opus 5.5). У Gracile агенты плохо знали фреймворк и клонировали его репозиторий или читали скомпилированный код из node_modules. У Angular стоимость, похоже, зависит от общего объёма кода. Время и токены довольно близко следуют за стоимостью.

Использование инструментов. Не все агенты воспользовались MCP, навыками или плагином: агент TanStack Start нашёл файлы навыков лишь в 2 из 5 запусков, в Nuxt MCP не использовали ни разу, в Next.js навык прочитали в 1 из 5 запусков, а AGENTS.md, в 2 из 5. Автор считает это допустимым: вряд ли многие вайб-кодеры требуют от агентов использовать MCP. Hono+htmx он выбрал, чтобы был представлен htmx, Gracile+Lit, чтобы были представлены веб-компоненты. «Vanilla», это JavaScript или TypeScript с Vite без UI-фреймворка: по стоимости он, к удивлению автора, уступает нескольким фреймворкам, из чего автор делает вывод, что какой-то фреймворк может быть лучше, чем ничего.

Качество. Оценки Lighthouse по производительности, доступности и CLS почти «насыщены» и мало зависят от фреймворка. Самая надёжная различающая метрика, объём отправляемого JavaScript, он в основном следует размеру клиентской части фреймворка. Total Blocking Time (TBT) не сводится к байтам JavaScript, но значения везде небольшие. Largest Contentful Paint (LCP) очень изменчив, но в целом наказывает SPA и поощряет MPA; без учёта разброса он в основном определяется размером JavaScript-бандла (исключение, Qwik: технически SPA с клиентской маршрутизацией, но по LCP среди MPA). Разброс у Next.js объясняется тем, что одно приложение не использовало ленивую загрузку изображений, а остальные четыре использовали. Автор предупреждает, что Lighthouse и Core Web Vitals смещены против SPA, поэтому MPA-фреймворки почти гарантированно выигрывают по TBT и объёму JavaScript. Агент Gracile в двух запусках вообще не использовал Lit, а «Vanilla»-агент все 5 раз выбрал SPA.

Сопровождаемость автор измерял самым простым способом, общим числом строк кода. Он цитирует Рича Харриса о том, что фреймворки, это инструменты организации мышления, и добавляет, что в эпоху агентов размер кода влияет на число токенов, в том числе в будущих правках, то есть на буквальную стоимость поддержки. По его наблюдению, Hono+htmx делает примерно то же, что Angular, с примерно 70% кода (и быстрее). Текст доступного материала обрывается в заключении: там автор лишь начинает перечислять, как можно улучшить бенчмарк (например, потребовать Service Workers для офлайн-кэширования или оптимизировать изображения).

Ключевые факты

Одно и то же приложение про покемонов (PokéAPI, контентный сайт с малой интерактивностью) собирал агент Opus 5.5 с высоким уровнем усилий на каждом фреймворке; для каждого брали медиану из 5 запусков, соответствие спецификации проверялось набором тестов.
Дороже остальных в сборке вышли SvelteKit, Gracile+Lit и Angular; по предположению автора, для SvelteKit причина в чтении руководства по миграции на v3 в каждом запуске, для Angular, в общем объёме кода.
Разброс затрат велик: самый дешёвый запуск React Router ($2,82) дешевле самого дорогого запуска Hono+htmx ($3,19), хотя медиана React Router примерно на $1 выше.
Оценки Lighthouse по производительности, доступности и CLS почти не различаются; надёжнее всего различает объём отправляемого JavaScript, а LCP в целом поощряет MPA и наказывает SPA.
Hono+htmx, по оценке автора, делает примерно то же, что Angular, примерно с 70% кода; «чистый» Vanilla с Vite по стоимости уступил нескольким фреймворкам.

Почему это важно

Решения о выборе фронтенд-фреймворка всё чаще объясняют тем, что он «лучше для агентов», и обычно без измерений. Автор делает попытку заменить ощущения данными: стоимость сборки, токены, время, объём кода и метрики Lighthouse. Главный практический вывод в том, что разница между фреймворками по стоимости есть, но отдельные запуски сильно пересекаются по цене, а у части фреймворков (SvelteKit, Gracile+Lit, Angular) устойчиво дороже. Автор также связывает размер кода с будущей стоимостью поддержки в эпоху агентов: чем больше кода, тем больше токенов на каждую правку.

Кому это важно

Командам и разработчикам, которые выбирают или меняют фронтенд-стек с расчётом на работу кодинг-агентов; авторам фреймворков и инструментов для агентов (MCP, навыки, AGENTS.md), для которых результаты показывают, что агенты их нередко не используют (TanStack Start, навыки найдены в 2 из 5 запусков, Nuxt, MCP ни разу, Next.js, навык в 1 из 5 и AGENTS.md в 2 из 5); тем, кто следит за производительностью веб-страниц.

Как это применить

Сам бенчмарк, шаблон для собственных проверок: единая спецификация, набор тестов на соответствие, строящихся на дереве доступности, несколько запусков с медианой и учёт разброса. Цифры автора стоит читать как ориентир для контентного сайта с малой интерактивностью, а не как рецепт для сложных приложений. Агент пробовал каждый фреймворк с официальным MCP или навыками, поэтому вывод о дороговизне новых или малоизвестных фреймворков (агенты читают миграционные руководства и исходники) можно учитывать, оценивая издержки.

Можно ли доверять

Это личный блог, автор сам подчёркивает ограничения: одно небольшое контентное приложение, одна модель (Opus 5.5, high effort), стохастичность агентов и самого Lighthouse, непостоянный LCP. Приведены медианы 5 запусков, а разброс признан честно. Для Angular часть метрик посчитана по 3 итерациям. Стоимость, это API-цены из Claude Code, а не реальные расходы. В доступном тексте нет самих значений на графиках, только пересказ, и текст обрывается в заключении, поэтому итоговые выводы автора не видны. Причины высокой стоимости SvelteKit и Angular автор формулирует как предположения.

Риски и подводные камни

Lighthouse и Core Web Vitals смещены против SPA, поэтому MPA-фреймворки почти гарантированно выигрывают по TBT и объёму JavaScript; автор отказался вводить собственные метрики приложения. Результаты нельзя переносить на большие сложные приложения. Часть запусков не вполне сопоставима: Gracile в двух запусках обходился без Lit, Vanilla всегда выбирал SPA, а архитектуру агентам не задавали. Сопровождаемость измерялась лишь общим числом строк кода. Разные сбои вроде ленивой загрузки изображений в Next.js тоже искажают отдельные метрики.

«Фреймворки, это не инструменты для организации вашего кода; это инструменты для организации вашего мышления.»

— Рич Харрис, «Rethinking reactivity» (цитата в статье)