2026/11/01 15:06
JavaScript フレームワークのコスト
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Web 開発コミュニティは、しばしば「雰囲気」に基づいてフレームワークを選択する傾向があり、著者はそのような慣習を AI コーディングの時代においても批判しています。この問題を解決するために行われたベンチマークでは、AI エージェントが PokéAPI を使用して非自明なポケモンアプリケーションを構築し、十二つの JavaScript フレームワーク/メタフレームワーク（Astro、Next.js、Angular 等）における結果を比較しました。Opus 5.5 と公式 MCP スキルを活用し、AI の予測不可能性を低減させるために各フレームワークごとに五回の実行で結果を平均化して評価しました。その調査結果は、軽量なソリューションである Astro や Hono+htmx が AI トークン使用量（$2.67–$2.76）においても最も低く、かつウォールクロックでの実行時間（Angular の 17.2 分に対して 8.2 分）も短く、データ転送サイズ（軽量 SPAs は 10 KiB 未満、重い SPAs では 100 KiB を超える）も著しく小さいことを示しています。Lighthouse スコアは概ね高く揃っていましたが、Single Page Applications (SPAs) に対する既知のバイアスにより、Largest Contentful Paint などの指標にわずかなばらつきが生じました。可搬性（ maintenability）はコード行数で測定され、軽量フレームワークが強く優位でした。この証拠に基づいた研究は、開発者を無根拠な主張から遠ざけ、個人プロジェクトおよび大規模企業双方においてコスト、効率性、可搬性を最適化するツール選定を促すよう呼びかけます。
本文
Web 開発における「感覚」からの脱却：AI エージェントベンチマークによる事実解明
Web 開発コミュニティにおいて著しい不満を抱える理由の一つは、我々の決断の多くが「感覚（バイブス）」に基づいているという点にあります。
- 「爆速なフレームワーク」や「開発力をスーパーチャージするツール」といった表現は根拠のない吹聴であることが多いです。
- アレックス・ラッセルはこれを「フロントエンドの失われた 10 年」と呼びました。
- バルドル・ヤーナソンはプログラミングをポップカルチャーと位置づけました。
- 著者は事実やベンチマークに基づき、この傾向に立ち向かわんとしました。
開発者体験（DX）への盲目な渇望
長らくコミュニティにおいて「根拠」が軽視されるのは、より優れた DX を求める欲望から来ているように見えました。
- React で JSX が書けること自体を「心地よい」と感じることは本質です。
- 「仮想 DOM は速い！」などの議論は、その直感への正当化（後付けの弁解）に過ぎない場合が多いです。
エージェント時代の「バイブス」問題
現在では開発者がコードを手入力する機会が減っており、DX に縛られることが少ないにもかかわらず、「バイブス」が依然として支配的です。
- 「あるフレームワークは AI エージェントと相性が良い」という理由だけで書き直すケースが多いです。
- 実際には「エージェントに聞いてみましたか？」という問いに対して十分な検証が行われていません。
ベンチマークの設計と方法論
著者が作成したベンチマークは以下の構成で進められました：
- タスク：PokéAPI を使用し、非自明なポケモンアプリを開発。
- ポケモンの一覧、タイプ、招式、ゲームデータ、検索・フィルタリング機能を含む。
- 手法：
- AI エージェントに特定のフレームワークまたはメタフレームワークを使用させさせる。
- 出力結果を「適合性スイート」でテスト（エージェントによるチート防止）。
- 評価指標：
- 開発時間
- 消費トークン数
- コード行数
- Lighthouse パフォーマンススコア・アクセシビリティスコア
アプリケーションの特性と制限事項
- これは単一のホロタイプ（原型）であり、インタラクティブ性は少ない Wikipedia 的な静的サイトです。
- Figma や GMail のような複雑なアプリではありませんが、比較・理解・テストに最適です。
実験の公平性を確保するための設定
- MCP/スキルの強制：フレームワーク公式の MCP（Machine Communication Protocol）またはスキルを使用するように指示。
- これにより「トレーニングデータにないため MCP を構築した」という批判を回避。
- アーキテクチャの指定なし：SSR か CSR か、パフォーマンス最大化は指示せず。
- 評価への事前知識なし：Lighthouse テストや適合性テストスイートの存在についてはエージェントに知らせず。
CSS メソドロジーについて
- Tailwind や Bootstrap などのコンポーネントフレームワークは使用禁止（視覚的統一のため仕様トークンベースのみ）。
- JS フレームワーク、CSR/SSR、SPA/MPA の比較に焦点を当てたいため。
- アクセシビリティツリーに基づくテストを実装（一部の Web Components 対応のため必須）。
確率的変動への対処
- LLM はランダムな生成器であり、エージェントの脱線や Lighthouse の結果の一貫性欠如は避がれません。
- 複数の回数を走行させ、変動率を正直に報告する方針です。
ベンチマーク結果
以下の項目で分析を行いました：
- 構築コスト
- 品質（パフォーマンス・アクセシビリティ）
- 保守性（コード量）
※すべての数値は 5 回の実行の中央値です。
例外：Angular は測定可能なアプリ作成に 2 回失敗したため、一部の指標では 3 回の値を採用。
1. コスト（構築費用）
各実行あたりの API 費用（米ドル）です。 (注：Claude Code の API 価格引用であり、実費ではありません)
| フレームワーク | 費用 ($) (中央値 / 範囲) |
|---|---|
| Hono+htmx | $2.67 (2.23–3.19) |
| Astro | $2.76 (2.16–3.63) |
| Nuxt | $2.82 (2.39–4.25) |
| Vanilla | $2.98 (2.24–3.37) |
| Next.js | $3.14 (2.58–4.13) |
| Qwik | $3.27 (2.35–3.80) |
| TanStack Start | $3.54 (3.11–3.96) |
| SolidStart | $3.79 (2.84–4.81) |
| React Router | $3.81 (2.82–3.97) |
| SvelteKit | $4.28 (3.59–4.65) |
| Gracile+Lit | $4.65 (3.92–5.07) |
| Angular | $4.97 (3.19–6.82) |
費用の傾向と分析
- 高コストの原因：SvelteKit、Gracile+Lit、Angular が他社より高額でした。
- SvelteKit: v3 移行ガイドの読み込み（トレーニングデータ不在）。
- Gracile: フレームワークの不備によりリポジトリクローンやソースコード参照が必要。
- Angular: コード総量に起因。
- ツール利用状況：すべてのエージェントが MCP/スキルを使用したわけではありません。
- React Router、Hono+htmx はスキルフル活用（5/5）。
- TanStack Start や Next.js ではスキルファイルの発見率が低かった（LLM の確率的性質による）。
2. コスト以外の指標：時間とトークン数
時間（各実行あたりの所要時間）
| フレームワーク | 時間 (分) (中央値 / 範囲) |
|---|---|
| Astro | 8.2 min (6.2–9.7) |
| Hono+htmx | 8.6 min (5.9–9.6) |
| Nuxt | 9.0 min (8.0–17.6) |
| Vanilla | 10.1 min (6.9–18.6) |
| ... | ... |
| Astro | 最速 (8.2 分) |
トークン（各実行あたりの使用数）
| フレームワーク | トークン (M) (中央値 / 範囲) |
|---|---|
| Nuxt | 3.85 M (3.16–8.18) |
| Astro | 4.13 M (3.03–7.57) |
| Hono+htmx | 4.26 M (3.40–5.61) |
| Vanilla | 5.00 M (3.44–6.32) |
| ... | ... |
| Nuxt | 最少 (3.85M) |
3. 品質（パフォーマンス・アクセシビリティ）
Lighthouse スコアはほぼ飽和しており、フレームワーク間の差は僅かです。
| フレームワーク | CLS | パフォーマンス | アクセシビリティ |
|---|---|---|---|
| Angular | 0.000 | 98 | 100 |
| Astro | 0.000 | 100 | 100 |
| Gracile+Lit | 0.000 | 100 | 100 |
| ... | ... | ... | ... |
重要な指標：転送された JavaScript バイト数
クライアントサイドフレームワークのサイズが主要因です。
| フレームワーク | JS (KiB) |
|---|---|
| Astro | 0 KiB (0–1) |
| Vanilla | 7 KiB |
| Gracile+Lit | 8 KiB |
| Hono+htmx | 18 KiB |
| ... | ... |
| Next.js | 142 KiB |
Total Blocking Time (TBT)
メインスレッドでのブロック時間。SPA より MPA が有利。
| フレームワーク | TBT (ms) |
|---|---|
| Astro | 0 ms |
| Gracile+Lit | 0 ms |
| Hono+htmx | 0 ms |
| ... | ... |
| Angular | 103 ms |
Largest Contentful Paint (LCP)
画像の遅延読み込み回避の有無などで変動が激しいですが、SPA は罰せられ MPA が有利です。
- Astro: 810 ms
- Next.js: 2090 ms (最悪クラス)
結論として：LCP は主に JS バンドルサイズに依存します。Qwik は例外（SPA ですが MPA スコア圏内）。
4. 保守性（コード行数）
総コード行数は Angular が遥かに多く、Hono+htmx が圧倒的に少ないです。
| フレームワーク | コード行数 |
|---|---|
| Hono+htmx | 1370 |
| Nuxt | 1415 |
| Astro | 1461 |
| Vanilla | 1492 |
| ... | ... |
| Angular | 2009 |
Rich Harris の言葉：「フレームワークはコードを整理するためのツールではありません。心の整理のためのツールです。」
AI エージェント時代において、このコード量は将来の編集やトークン消費のコストに直結します。Hono+htmx は Angular とほぼ同等の結果を約 70% のコード量で達成（しかも高速）。
結論と考察
ベンチマークの改善点
- パフォーマンスハック（Service Worker、画像最適化、遅延読み込みなど）は意図的に避けた。
- 「静的資産としての HTML 生成」は禁止された。
- より多くの反復や異なるエージェント/バージョンでテストすることも可能であるが、今回は時間の制約で実施していない。
最終的なメッセージ
このベンチマークは「バイブスコーダーのための指針」としては不十分ですが、**「感覚ではなく根拠に基づいて決断できる」**ことを示す試みでした。
- 特定のフレームワークを非難する意図はありません。
- MPA が SPA より優れていることは既知の事実です。
- アプリケーションが複雑化すれば、SPA 有利なベンチマークや新たな指標も選べるでしょう。
開発者への問いかけ
この奇妙な新しい「バイブスコディング」時代において、あなたは慎重に検討していますか？
- 「npm install」後にタイプするものも再評価すべきかもしれません。
- 特に、完全に手放しで進めているなら、コードの各ラインを自分で読み込む頃のあなたへの愛着はどうでしょうか。
追記：使用フレームワークバージョン
| フレームワーク | バージョン情報 |
|---|---|
| Angular | @angular/core 22.2.3 |
| Astro | astro 7.4.2 |
| Gracile+Lit | @gracile/gracile 0.11.0, lit 3.3.3 |
| Hono+htmx | hono 4.13.14, htmx.org 2.0.11 |
| Next.js | next 16.4.3, react 19.3.1 |
| Nuxt | nuxt 4.6.2, vue 3.5.44 |
| Qwik | @builder.io/qwik-city 1.20.x (パッチ版あり) |
| React Router | react-router 8.5.0, react 19.3.1 |
| SolidStart | @solidjs/start 2.1.0, solid-js 1.9.17 |
| SvelteKit | @sveltejs/kit 3.1.0, svelte 5.57.2 |
| TanStack Start | @tanstack/react-start 1.169.4, react 19.3.1 |
| Vanilla | vite 8.3.5 |
Fediverse や Hacker News でコメント歓迎です。