測試方法與限制：基於 PokéAPI 的單一應用場景

Lawson 設計了一個基於 PokéAPI 的小型 Pokémon 應用程式，要求 AI 代理使用特定的 JavaScript 框架或元框架進行開發。測試對象包括 Next.js、Nuxt、SvelteKit、Angular、Astro、Qwik、SolidStart、React Router、TanStack Start、Gracile+Lit、Hono+htmx 以及不使用 UI 框架的 Vanilla (Vite)。

為了確保公平性，每個框架都使用了官方的 MCP (Model Context Protocol) 或技能文件。測試未指定具體架構（如 SSR 或 CSR），也未強制要求極致效能，僅提供規格說明並要求使用最新版本的框架。代理在沙盒環境中運行，且不知道會被 Lighthouse 進行性能與無障礙測試。

該測試存在明顯限制：應用場景偏向內容展示而非高互動性（類似 Wikipedia 而非 Figma），且 Lighthouse 指標本身對單頁應用 (SPA) 較為不利。此外，LLM 的隨機性導致結果波動大，Lawson 強調這是為了模擬真實開發者可能遇到的情況，而非追求絕對精確的實驗室數據。

建置成本與時間：SvelteKit 與 Angular 花費最高

在 API 呼叫成本方面，Hono+htmx (2.67 美元)、Astro (2.76 美元) 和 Nuxt (2.82 美元) 是最便宜的選項。相比之下，SvelteKit (4.28 美元)、Gracile+Lit (4.65 美元) 和 Angular (4.97 美元) 的成本顯著較高。

Lawson 分析指出，SvelteKit 成本偏高可能是因為 AI 代理每次運行都需讀取 SvelteKit v3 遷移指南，推測是因該版本過新而不在 Opus 5.5 的訓練數據中。Gracile+Lit 則因框架較冷門，代理需額外克隆倉庫或閱讀編譯後源碼。Angular 的高成本主要與生成的代碼總量成正比。

時間消耗與 Token 使用量與成本趨勢一致。Astro 和 Hono+htmx 平均耗時約 8-9 分鐘，而 Angular 平均需 17.2 分鐘。Token 消耗方面，Nuxt (3.85M) 和 Astro (4.13M) 較低，Angular (9.76M) 最高。值得注意的是，部分框架的 MCP 或技能文件並未被代理穩定使用，例如 Nuxt 的 MCP 在測試中從未被調用。

前端效能與代碼質量：Astro 零 JS 傳輸量勝出

Lighthouse 的性能、無障礙和累積佈局偏移 (CLS) 評分在所有框架中幾乎都達到飽和狀態（多數為 98-100 分），因此這些指標無法有效區分框架優劣。更具參考價值的是 JavaScript 傳輸量和總阻塞時間 (TBT)。

Astro 生成的應用僅需傳輸 0 KiB 的 JavaScript，Vanilla 為 7 KiB，而 Next.js 高達 142 KiB，TanStack Start 為 118 KiB。JavaScript 檔案大小直接影響 TBT，Astro、Gracile+Lit 和 Hono+htmx 的 TBT 為 0 ms，而 Angular 平均為 103 ms，Next.js 為 71 ms。

最大內容繪製 (LCP) 指標顯示多頁應用 (MPA) 通常優於單頁應用 (SPA)，因為 MPA 能更快透過 HTML 渲染內容。Astro 的 LCP 中位數為 810 ms，而 Next.js 為 2,090 ms。然而，LCP 數據波動極大，部分原因是圖片懶加載策略的不一致以及指標本身的計算特性，因此該數據僅供參考趨勢而非絕對標準。

代碼維護性：框架應減少代碼量而非增加

Lawson 將總代碼行數作為維護性的簡化指標。Hono+htmx (1,370 行)、Nuxt (1,415 行) 和 Astro (1,461 行) 生成的代碼最少，而 Angular (2,009 行) 最多。

Lawson 引用 Rich Harris 的觀點指出，框架的目的是組織思維而非僅組織代碼。在 AI 時代，較少的代碼量意味著未來進行維護或修改時，AI 代理需要處理的 Token 更少，從而降低長期維護成本。Hono+htmx 能以約 70% 的代碼量實現與 Angular 相同的功能，且執行速度更快。

測試中還發現一些異常行為：Gracile 代理在兩次運行中甚至沒有使用 Lit；Vanilla 代理雖被允許自由選擇，但五次運行均構建了 SPA；Angular 代理有兩次因 SSR 配置錯誤導致應用無法在非 localhost 環境運行而被視為失敗。

社群觀點與未來展望：證據導向的技術選型

Lawson 強調此測試並非為了證明哪個框架絕對最好，而是倡導在 AI 編程時代應基於證據而非直覺（Vibes）進行技術決策。他承認測試存在缺陷，如未優化圖片、未使用 Service Worker 等，且結果受 LLM 隨機性影響。

社群評論指出，企業選擇框架往往出於降低培訓成本和招聘便利性的考量，而非純粹的技術優勢。也有開發者建議利用 AI 現代化現有框架（如 Mithril）而非直接重寫到新框架。另有觀點認為，許多 SPA 框架作者未充分理解瀏覽器引擎運作機制，導致不必要的 DOM 操作成本。

Lawson 鼓勵其他開發者複製或改進此基準測試，並歡迎不同框架的作者優化其 AI 工具以提升表現。他認為目前的 MCP 和技能文件可能反而增加了複雜性，未來應探索更高效的代理輔助開發模式。