Большинство программистов JavaScript по умолчанию выбирают фреймворки, которым хранят верность до конца, но такая верность может помешать, когда они поручают AI-агентам грязную работу. Удобные для человека инструменты не обязательно наиболее эффективны для подручных на базе моделей.
«Одна из вещей, которые меня раздражают в сообществе веб-разработки, — то, что многие наши решения принимаются на основе ощущений», — написал базирующийся в Сиэтле Нолан Лоусон, сейчас разработчик в компании по безопасности AI Socket. Это ещё мягко сказано; войны JavaScript идут уже более десяти лет, и каждый новый фреймворк обещает излечить проблемы прошлогоднего релиза.
Не желая, чтобы эти субъективные предубеждения проникли в сферу AI, Лоусон создал бенчмарк для сравнения того, как разные фреймворки JavaScript работают с одной и той же агентной моделью. Затем он прогнал тест на 12 фреймворках JavaScript и опубликовал результаты в посте, где сравнил каждый фреймворк по стоимости сборки, поддерживаемости и производительности для конечных пользователей приложений, созданных агентами.
Результаты показательны. В целом агенты работают эффективнее с сервероцентричными фреймворками, чем с клиентоориентированными фреймворками для «одностраничных приложений» (SPA) (что должно порадовать ненавистников React).
Но главный вывод должен быть менее спорным: агенты лучше всего используют фреймворки, которые делают ставку на соглашения, стабильность API и лаконичность.
Как сравнивать фреймворки JavaScript
Для эксперимента Лоусон написал набор инструкций для агента Claude Code, чтобы тот создал базовое веб-приложение по «Покемону» с использованием PokéAPI. Модель использовала одинаковую конфигурацию на 12 разных фреймворках и стеках JavaScript: Angular, Astro, Gracile с Lit, Hono с htmx, чистый JavaScript с Vite, Next.js, Nuxt, Qwik, React Router, TanStack Start, SolidStart и SvelteKit.
Лоусон оценивал каждый стек в пяти независимых запусках в песочнице; повторные итерации сгладили разброс в производительности модели.
Чтобы проверить, соответствует ли полученное приложение требованиям, Лоусон развернул собственный набор автоматизированных тестов, который обращался к дереву доступности браузера, чтобы убедиться, что интерактивные элементы вроде кнопок и полей ввода не были поддельными, — уловка, к которой LLM иногда прибегают. Лоусон также использовал Google Lighthouse для измерения размера передачи и производительности во время выполнения.
Если фреймворки указывали официальные серверы MCP, плагины Claude и файлы навыков агента, Лоусон предоставлял их агентам как ресурсы (хотя к ним не всегда обращались). В остальном он не требовал какой-либо конкретной архитектуры для рендеринга приложения.
Сравнение 12 фреймворков JavaScript
Различия между самыми экономичными и самыми дорогими сборками, мягко говоря, существенны: лидеры заметно опережают отстающих.
Если вы хотите экономично построить Покемир, лучшая ставка — Hono в паре с htmx. Эта связка технологий показала самый экономичный запуск: медианная стоимость составила $2,67 за поке-приложение.
Возможно, это неудивительно, учитывая, что эта пара полностью работает на сервере, устраняя целый набор проверок, необходимых для синхронизации архитектурного разделения клиента и сервера. Это также помогло минимизировать код, что привело к меньшему расходу выходных токенов.
Почти столь же эффективным оказался Astro ($2,76). Как и Hono/htmx, Astro выполняет всё на стороне сервера. Серверная обработка данных также помогла Astro достичь самого быстрого медианного времени сборки и тестирования приложения — 8,2 минуты.
Nuxt ($2,82) оказался самым экономичным вариантом для подхода, похожего на SPA. Nuxt рендерит код на сервере, который затем гидратируется на клиенте. На самом деле Nuxt построен на Vue.js, но он «opinionated»: устраняет множество шаблонного кода, который иначе пришлось бы писать агенту. Nuxt также внутренне обрабатывает передачу данных и маршрутизацию файлов — ещё один пласт кода, о котором не нужно беспокоиться.
Стоит также отметить, что Nuxt потребил меньше всего токенов из всех (3,85 млн), хотя это не сделало его самым дешёвым, учитывая, что Claude взимает разные ставки за входные и выходные токены. Nuxt создал приложение в 1 415 строках кода — второй результат после 1 370 строк у Hono/htmx.
В целом эти три лучших фреймворка оказались в пределах погрешности друг друга, а значит, любой из них мог получить высший балл в зависимости от того, насколько удачным был день у LLM.
Однако некоторые более традиционные фреймворки сильно отстали.
Приложение на SvelteKit стоило $4,28 на генерацию: агент раз за разом возвращался к документации SvelteKit, чтобы лучше разобраться в работе недавно обновлённого Svelte. Angular оказался самым дорогим способом для агента построить приложение — $4,97, 17,2 минуты и 9,76 млн токенов (причём в двух из пяти попыток агент даже не смог завершить рабочее приложение).
Все полученные приложения на отлично прошли тесты доступности и производительности Lighthouse. Лоусон признал, что это довольно простое для рендеринга приложение.
Приложение Astro показало самое быстрое время загрузки (Largest Contentful Paint, или LCP) — 810 мс, тогда как самые медленные фреймворки в группе — Next.js (2 090 мс) и TanStack Start (2 028 мс) — выдали результат более чем вдвое дольше, возможно, из-за всего JavaScript, который они отправили клиенту.
Золотые звёзды всем
Лоусон надеется, что эта работа создаст основу для более строгого подхода к выбору фреймворков для задач AI, поскольку разработчикам больше не придётся выполнять основную тяжёлую работу самим.
Но несколько разработчиков на Hacker News указали, что эффективность AI — не единственный фактор, который стоит учитывать. Есть ещё человеческий компонент поддержки фреймворка.
«После десяти лет с React я не собираюсь учить htmx или любой другой немного лучший инструмент той же формы для нового проекта, особенно если это ухудшит мою способность проверять и отлаживать результаты работы другого исполнителя», — написал один из них.
В конце концов, сами фреймворки могут развиваться с помощью AI, со временем сокращая различия. «Помимо переписывания под другой фреймворк с помощью AI, есть и другой вариант — модернизировать сам фреймворк с помощью AI», — отметил кто-то ещё. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Joab Jackson
