JavaScript-фреймворки: стоимость разработки с ИИ

Для приложения с упором на контент сначала рассмотрите Hono+htmx и Astro, если важны расходы на ИИ. В тесте Нолана Лоусона минимальная медианная стоимость по расчёту Claude Code — $2.67 у Hono+htmx против $4.97 у Angular. Для существующего проекта сначала сравните затраты на типичную доработку, прежде чем менять фреймворк.

Какой фреймворк оказался дешевле?

По этой таблице можно выбрать кандидатов для пробного запуска на приложении с упором на контент. Лоусон опубликовал эксперимент 28 октября 2026 года. В опубликованных запусках и измерениях использовались Claude Code 2.1.310 и модель claude-opus-5-5 с уровнем рассуждений high.

Каждый агент создавал одно и то же приложение с данными PokéAPI, поиском, фильтрами и страницами с подробной информацией. Таблица объединяет опубликованные результаты по состоянию на 2026-11-06. Версии указывают, какие пакеты участвовали в эксперименте; это не рекомендация устанавливать их сегодня.

Фреймворк и версия в тесте	Расчётная стоимость API, USD: медиана (мин.–макс.)	Время, мин	Токены, млн	Строки исходного кода
Hono 4.13.14 + htmx 2.0.11	$2.67 ($2.23–$3.19)	8.6	4.26	1,370
Astro 7.4.2	$2.76 ($2.16–$3.63)	8.2	4.13	1,461
Nuxt 4.6.2	$2.82 ($2.39–$4.25)	9.0	3.85	1,415
Vanilla с Vite 8.3.5	$2.98 ($2.24–$3.37)	10.1	5.00	1,492
Next.js 16.4.3	$3.14 ($2.58–$4.13)	10.9	4.99	1,539
Qwik 1.20.2 / 1.20.3	$3.27 ($2.35–$3.80)	10.7	5.64	1,744
TanStack Start 1.169.4	$3.54 ($3.11–$3.96)	10.3	7.07	1,697
SolidStart 2.1.0	$3.79 ($2.84–$4.81)	11.2	7.13	1,630
React Router 8.5.0	$3.81 ($2.82–$3.97)	12.5	7.58	1,564
SvelteKit 3.1.0	$4.28 ($3.59–$4.65)	10.8	8.53	1,611
Gracile 0.11.0 + Lit 3.3.3	$4.65 ($3.92–$5.07)	12.1	9.04	1,717
Angular 22.2.3	$4.97 ($3.19–$6.82)	17.2	9.76	2,009

Для каждого показателя медиана рассчитана отдельно. Стоимость, время и токены учитывают пять попыток для каждого фреймворка. Размер кода Angular рассчитан по трём приложениям: два других не удалось измерить при работе через обратный прокси.

В общее число токенов входят некешированный ввод, запись в кеш, чтение из кеша и вывод за весь сеанс. При подсчёте строк исключены пустые строки, JSON, тесты и lock-файлы, которые фиксируют версии зависимостей. Сгенерированные файлы и копии предоставленных файлов дизайна тоже исключены; комментарии учитываются.

Суммы в долларах — расчётная стоимость по тарифам API, которую показывает Claude Code. Лоусон работал по подписке, поэтому таблица не отражает его фактические платежи за каждое созданное приложение. В неё также не входят стоимость хостинга и время ручной проверки.

По округлённым медианам разница между Angular и Hono+htmx составляет $4.97 − $2.67 = $2.30. Отношение — 4.97 / 2.67 ≈ 1.86: в этой задаче Angular обошёлся примерно на 86% дороже.

Разница между Next.js и Astro — $0.38 на создание приложения, причём наблюдаемые диапазоны перекрываются. У Hono+htmx и Astro разница составляет всего $0.09. При таких различиях сначала проведите небольшой тест на своей задаче: уверенного универсального рейтинга эти данные не дают.

Почему SvelteKit и Angular обошлись дороже?

Дополнительное чтение документации и больший объём кода могли повысить стоимость, но их вклад здесь не измерен отдельно.

Лоусон наблюдал, что агент SvelteKit читал руководство по переходу на v3 в каждом запуске. По его предположению, v3 могла быть слишком новой для обучающих данных модели. В официальном руководстве по миграции описаны изменения, в том числе перенос конфигурации в Vite. Само руководство не подтверждает, какие сведения попали в обучающие данные модели.

В случае Gracile Лоусон описывает клонирование репозитория или чтение скомпилированных файлов из node_modules. Агенту приходилось дополнительно изучать код. Какую долю разницы в стоимости объясняют эти чтения, в эксперименте не измеряли.

Медианный объём исходников Angular — 2,009 строк против 1,370 у Hono+htmx. Показатель Hono+htmx составляет около 68% от Angular, что согласуется с приблизительной оценкой Лоусона в 70%. Большие файлы могут увеличить объём чтения и правок в будущих задачах, но стоимость сопровождения здесь не измеряли.

Общее число токенов тоже нужно трактовать осторожно. У Nuxt самая низкая медиана — 3.85 млн токенов, но не самая низкая стоимость. Кеш меняет соотношение между общим числом токенов и ценой. Поэтому при сравнении затрат учитывайте категории токенов отдельно.

Помогают ли MCP-серверы и навыки фреймворков?

Тест не позволяет установить, снижают ли MCP-серверы и навыки стоимость работы агента. Он показывает неравномерное использование инструментов, но не сравнивает каждый фреймворк с ними и без них.

MCP-сервер подключает к агенту внешние инструменты. Навыки (skills) задают агенту инструкции для определённых задач. Лоусон установил официальные инструменты там, где они были доступны; у нескольких фреймворков таких инструментов не было.

Он зафиксировал следующие результаты:

Фреймворк	Использование в пяти запусках
Hono+htmx	Инструмент Skill для Hono использован в 5/5 запусков
SvelteKit	MCP использован в 5/5 запусков
Nuxt	MCP использован в 0/5 запусков
Next.js	Файлы навыков прочитаны в 1/5 запусков; AGENTS.md — в 2/5
TanStack Start	Файлы навыков из пакета найдены в 2/5 запусков

То, что агент не вызвал MCP Nuxt, не доказывает его бесполезность. Более высокая стоимость SvelteKit тоже не доказывает, что её вызвал MCP. Проверяйте отдельно установку инструмента, его вызов и снижение затрат на завершённую задачу.

В актуальном руководстве Next.js документация под установленную версию отделена от навыков, которые задают порядок работы. Записывайте, к какому ресурсу обращался агент. Чтение документации само по себе не означает вызов MCP.

В своём тесте сначала проверьте доступность сервера через claude mcp list или /mcp. Затем посмотрите фактические вызовы инструментов. Сравните один фреймворк в трёх условиях: без инструментов, с доступными инструментами и с прямым указанием их использовать. Подробнее о замерах — в руководстве по измерению вклада MCP в контекст.

Чего не показывает этот эксперимент?

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

• Тип приложения: каталог с небольшой интерактивностью не представляет сложный редактор, дашборд или игру. Архитектуру рендеринга агенты тоже выбирали сами.
• Выборка: пять попыток показывают примеры и разброс, но не позволяют уверенно ранжировать близкие результаты. Диапазоны в таблице — наблюдаемые минимумы и максимумы, а не доверительные интервалы.
• Среда: тест охватывает одну модель, один агент и один уровень рассуждений. После первого запуска Qwik изменился с 1.20.2 на 1.20.3. В двух попытках агент не использовал Lit, хотя задание требовало Gracile+Lit.
• Результат: Lighthouse с мобильными настройками оценивает загрузку страниц, но не охватывает все взаимодействия и требования к рабочему приложению. Число строк показывает размер кода; стоимость его сопровождения здесь не проверяли.

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

Как измерить стоимость Claude Code в своём проекте

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

1. Зафиксируйте задачу и исходное состояние

Сравнивайте одну небольшую доработку с одинаковыми приёмочными проверками. Для существующего продукта оставьте текущий фреймворк одним из кандидатов. Если тестируете правку, подготовьте оба стартовых проекта до начала замера времени; при создании с нуля включите подготовку в оба варианта.

Опишите конкретную задачу в SPEC.md. Например, подготовьте аналогичные страницы каталога и одинаковый набор тестовых данных товаров, затем задайте агенту:

Add case-insensitive name search to the catalog.
Read products from the existing fixture.
Persist the search query in the URL across reloads.
Show an accessible empty state when nothing matches.
Keep existing routes and the acceptance tests unchanged.

Зафиксируйте версии зависимостей и сохраните lock-файлы. Перед тестом доработки установите зависимости. Убедитесь, что оба проекта поддерживают npm run build и npm test. Сохраните отдельную нетронутую копию приёмочных тестов.

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

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

2. Сохраните данные запуска и итоговый результат

Используйте Bash, авторизованный Claude Code и установленный jq. Проверьте авторизацию командой claude auth status --text. При необходимости сначала выполните claude auth login.

Запускайте тест во временном контейнере для разработки. Настройки в примере разрешают агенту менять файлы и выполнять команды оболочки без подтверждения. Заранее разрешите нужные вызовы MCP через правила разрешений. Убедитесь, что эти правила загружаются в каждом тестовом окружении: одного подключения сервера недостаточно.

Для каждого варианта теста задавайте отдельный trial_label. Пример использует документированный неинтерактивный режим CLI и создаёт уникальный каталог для результатов.

trial_label=astro-01
trial_dir=$(mktemp -d "/tmp/${trial_label}.XXXXXX") || exit 1

claude --version > "$trial_dir/claude-version.txt"
git rev-parse HEAD > "$trial_dir/commit.txt"

trial_status=0
CLAUDE_CODE_EFFORT_LEVEL=high claude -p \
  --model claude-opus-5-5 \
  --max-budget-usd 10 \
  --allowedTools "Read,Edit,Write,Bash" \
  --output-format stream-json --verbose \
  "Implement SPEC.md without changing dependencies or acceptance tests. Run npm run build and npm test. Report incomplete work." \
  > "$trial_dir/session.jsonl" 2> "$trial_dir/stderr.log" \
  || trial_status=$?

printf '%s\n' "$trial_status" > "$trial_dir/exit-code.txt"

jq -s '
  [.[] | select(.type == "result")] | last
  | if . == null then error("No final result; record an incomplete run")
    else {
      session_id,
      subtype,
      is_error,
      estimated_usd: .total_cost_usd,
      reported_wall_minutes: (.duration_ms / 60000),
      modelUsage,
      permission_denials
    } end
' "$trial_dir/session.jsonl" > "$trial_dir/summary.json"

cat "$trial_dir/summary.json"
printf 'Results: %s\n' "$trial_dir"

Порог $10 выбран для примера. Флаг --max-budget-usd опирается на оценку стоимости API, и расходы могут превысить порог. Задайте одинаковый порог для всех вариантов и фиксируйте остановки по бюджету.

По состоянию на 2026-11-06 CLAUDE_CODE_EFFORT_LEVEL имеет приоритет над --effort. Заданный организацией предел уровня рассуждений по-прежнему действует. Если запустить выбранную модель не удаётся, проверьте настройки Opus 5.5 до продолжения сравнения.

Сводка должна содержать estimated_usd, reported_wall_minutes, modelUsage и сведения об отказах в permission_denials. Журнал JSONL сохраняет события инструментов для проверки. Убедитесь, что указана нужная модель, и отдельно отметьте все дополнительные модели, которые использовались.

3. Сравните проверенные результаты и учтите неудачные попытки

Используйте modelUsage для учёта токенов агента и субагентов. Храните отдельно inputTokens, outputTokens, cacheReadInputTokens и cacheCreationInputTokens. Поле usage итогового сообщения не учитывает токены субагентов.

Берите показатели из итогового сообщения один раз. Не складывайте накопительные суммы нескольких итоговых сообщений и не используйте возобновлённый сеанс как новую попытку.

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

Если итогового сообщения нет или оно некорректно, изучите stderr.log и отметьте попытку как незавершённую с неизвестной стоимостью. Не подставляйте ноль. Прежде чем объяснять отсутствие вызовов MCP поведением агента, устраните отказы в разрешениях.

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

Total quoted cost of all attempts / Number of accepted results

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

При работе вручную Claude Code показывает оценку стоимости в /usage. В справочнике команд /cost указан как псевдоним этой команды по состоянию на 2026-11-06. Лимиты подписки и фактические списания провайдера учитывайте отдельно от этой оценки.

Сохраните текущий стек, если небольшая экономия токенов не оправдывает расходы на проверку или миграцию. Пересмотрите выбор, когда другой вариант в повторных попытках проходит те же проверки при приемлемых затратах на поддержку.

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