作者自己跑的一次實驗
本文整理前端工程師 Nolan Lawson 的部落格文章（2026-10-28）。以下數據全是作者本人的實驗與量測，結論也是他的觀點；他自己也強調實驗不完美、結果有很大隨機性。
實驗方式：
- 規格：一個用 PokéAPI 的小型 Pokémon 網站（可搜尋、篩選）
- 讓 Opus 5.5（high effort）分別用 12 種框架開發，並安裝各框架官方的 MCP 或 skills
- 用一致性測試確認符合規格，再用 Lighthouse 量測效能
- 每種框架做 5 次取中位數（Angular 有 2 次無法量測，部分指標只用 3 次）
成本：Hono+htmx 最低，Angular 最高
【作者量測｜每次建置中位數】
| 框架 | 成本（美元） | 時間（分鐘） | Token（百萬） |
|---|---|---|---|
| Hono+htmx | 2.67 | 8.6 | 4.26 |
| Astro | 2.76 | 8.2 | 4.13 |
| Nuxt | 2.82 | 9.0 | 3.85 |
| Vanilla（Vite） | 2.98 | 10.1 | 5.00 |
| Next.js | 3.14 | 10.9 | 4.99 |
| SvelteKit | 4.28 | 10.8 | 8.53 |
| Gracile+Lit | 4.65 | 12.1 | 9.04 |
| Angular | 4.97 | 17.2 | 9.76 |
（節錄 8 種；成本是 Claude Code 顯示的 API 價格，作者實際用的是 Max 方案。）
作者觀察：SvelteKit 每次都去讀 v3 遷移指南，可能因為版本太新、不在模型訓練資料內；Gracile 則是 agent 不熟，跑去翻原始碼。另外，官方 MCP／skills 不一定會被用到，例如 Nuxt 的 MCP 5 次都沒被呼叫。
效能差在 JS 大小與程式碼量
Lighthouse 的效能、無障礙與 CLS 分數幾乎都接近滿分，差異主要在：
- 傳送的 JS：Astro 約 0 KiB、Vanilla 7 KiB、Hono+htmx 18 KiB，Next.js 則是 142 KiB
- 程式碼行數：Hono+htmx 約 1,370 行，Angular 約 2,009 行；作者指出前者只用約七成程式碼就做到同樣的事
- 作者也提醒：Lighthouse 天生對 SPA 不利，這個網站也偏內容型，結果不代表複雜的互動式應用
在 AI 時代，程式碼越多，後續每次修改要讀的 token 就越多，行數直接變成維護成本。
選技術棧前先問的 4 件事
把作者的觀點轉成實用建議：
- 你的網站偏內容還是偏互動？ 內容型網站可優先考慮 Astro、Hono+htmx 這類 MPA 做法；複雜儀表板則不能只看這份結果
- 模型熟不熟這個框架？ 太新的大版本，agent 常要邊讀文件邊做，token 會變多
- MCP／skills 有沒有真的被用？ 裝了不代表會被呼叫，必要時在提示裡明確要求
- 自己跑一次小型 benchmark：作者把測試開源，換成你的需求跑幾次，比聽口碑可靠
作者的核心訊息是：AI 時代選框架，也應該看證據，而不是看感覺。
