先問：「backend」是什麼場景
如果有人問你「哪個 Node.js framework 最好」，正確的回答不是 Express 或 NestJS，而是「你在做什麼？」
「backend」這個詞包含的場景差太多了：
- 一個處理 webhook 的 serverless function，一天被呼叫 10 次
- 一個電商 API，同時承載 5000 個 concurrent request
- 一個 50 人工程團隊共同維護的企業後台
- 一個需要在 Cloudflare Edge 跑的全球部署 API
這四個場景對 framework 的要求几乎沒有交集。Serverless function 要的是輕、冷啟動快；高 QPS API 要的是吞吐量和效能；大型企業系統要的是架構強制性、DI、模組邊界；Edge 部署要的是跨 runtime。
這就是為什麼同一個語言需要好幾個 framework——不是因為有人喜歡重複造輪子，而是這幾個需求本質上互相矛盾。
三條分裂軸線
軸線一：設計哲學（Minimal vs Batteries-Included）
Minimal（Express、Flask、Gin）：只給你最核心的路由和 middleware，其他都自己選。
優點：輕量、靈活、可控。你選了哪個 ORM、哪個 validation library，一眼看得清楚。
缺點：每個專案的結構都不一樣。新人進來要先花時間搞懂這個專案的規矩是誰定的、為什麼這樣定。
Batteries-Included（Django、Spring Boot、Laravel）：ORM、auth、migration、admin panel 全部內建或有官方整合，決策已經替你做好了。
優點：不需要花時間做技術選型，直接照著框架的 convention 走就有 production-ready 的結構。
缺點：帶著你用不到的東西。如果你只是要做一個 JSON API，Django 的 template engine、admin system 全是 overhead。
這兩種哲學的使用者通常很不一樣：Minimal 框架的使用者傾向有強烈的技術偏好，想控制每一層的選擇；Batteries-Included 的使用者傾向優先考慮開發速度和 convention 統一性。
軸線二：目標 Runtime（Platform-Specific vs Cross-Runtime）
早期的 framework 都只鎖定一個 runtime：Express 跑在 Node.js、Django 跑在 CPython、Spring 跑在 JVM。
2020 年之後，runtime 多樣化了：Bun、Deno、Cloudflare Workers、Vercel Edge Runtime 各有各的 API 和限制。傳統 framework 用的 Node.js-only API（fs、net、child_process）在這些環境裡跑不了。
Hono 解的就是這個問題——同一份 code 可以跑在 Node.js / Bun / Cloudflare Workers / Deno。Elysia 則是 Bun-first，充分利用 Bun 的效能特性。這兩個 framework 之所以存在，不是因為 Express 不好，而是 runtime 的版圖改變了。
軸線三：使用規模（個人 / 小團隊 vs 大型系統）
Express 在 5 人以下的小團隊很好用，但 50 人一起改同一個 codebase，每個人的寫法都不一樣，onboarding 新人的成本快速上升。
NestJS 借 Angular 的 Module / Injectable / Controller 架構強制統一寫法。不管是哪個工程師寫的 module，結構都一樣——代價是學習曲線高，不熟悉 DI / decorator 的人上手很慢。
小系統用 NestJS 是殺雞用牛刀；大系統用 Express 是在沙灘上蓋房子。這兩個框架解的不是同一個問題。
為什麼不「演進成一個最好的」
直觀上你可能會問：框架競爭了這麼多年，為什麼沒有一個贏家通吃？
因為不同的 trade-off 服務不同的場景，而這些場景是同時存在的，不會因為有了「更好的框架」就消失。
Express 的 minimal、生態大，在 2026 還是很多場景的正確答案——不是因為沒有更強的選擇，而是它的 trade-off 在那個場景仍然最合理。NestJS 的架構複雜度在小專案是負擔，在大型系統是護城河。
同理，Python 同時需要 Django（batteries-included、admin panel 無敵）和 FastAPI（async-first、Pydantic、OpenAPI 自動生成）——它們服務的不是同一群人。