本文整理自 2006 年對主流 Java Web 框架作者的訪談，雖年代久遠，但各框架核心設計哲學、適用場景、優缺點對比至今仍具參考價值，助你理解「為什麼選這個框架」。
| 框架 | 核心甜點 | 最適場景 | 不適場景 | 作者對 RoR 看法 |
|---|---|---|---|---|
| JSF (Jacob Hookom) | 元件化、工具支援豐富、標準化 (JSR)、第三方元件生態 | 複雜表單、企業級後台、需豐富 UI 元件 | 大型唯讀內容站、SEO 導向站點 | CoC 思想值得借鑑，但會走向複雜化 |
| Spring MVC (Rob Harrop) | 穩定擴展、最佳實踐內建、Spring 生態無縫整合、Struts 遷移平滑 | 請求驅動 MVC、REST API、微服務 | 高度元件化 UI | 有趣但尚嫩，CoC 在 Java 型別系統難落地 |
| Spring Web Flow (Keith Donald) | 內建流程引擎、線性流程狀態管理、可插入 Spring MVC/Struts/JSF | 精靈式流程、購物車、申請單 | 自由導航、非線性頁面 | 同 Spring MVC |
| Struts 1 (Don Brown) | 文檔/社群/人才最豐富、穩定、易招人 | 傳統專案維護、團隊皆熟 Struts | Portlet、複雜頁面組合 | Action 2 將吸收 RoR 精華 |
| WebWork (Patrick Lightbody) | 比 Struts 簡單、攔截器鏈、OGNL 表達式、Spring 整合佳 | 動作驅動 MVC、中型專案 | 複雜 UI 維護困難 | （併入 Struts 2） |
| Tapestry (Howard Lewis Ship) | 元件化極致、狀態管理強、易測試、IoC 深度整合 (HiveMind/Spring) | 中大型元件化應用、長期維護專案 | 嚴格 URL 格式需求 | 影響深遠，T5 吸收 CoC、Annotation、無 XML |
| Wicket (Eelco Hillenius) | 純 Java/HTML 分離、POJO 元件、無 XML、狀態自動管理、易測試 | 元件化、強型別、團隊偏好 Java 而非模板語言 | 大量靜態頁、SEO 導向 | （訪談中較少提及） |
| RIFE (Geert Bevin) | Full-stack、10% 代碼得 90% 功能、Continuation、無 Session 狀態、雙向無邏輯模板 | 快速開發公開 Web、可重用元件愛好者 | 團隊已熟悉他框架、XML 導向、需第三方生態 | 模板難用、URL 分散、Active Record 非領域驅動、無 i18n |
| Seam (Gavin King) | JSF + EJB3 整合、多視窗/工作區、BPM (jBPM)、對話上下文、無狀態瀏覽 | 豐富使用者互動、商務流程驅動、多工作區 | 單純 CRUD、JDK 1.4 環境 | PHP 替代品，持久層弱則難敵 Java |
| Stripes (Tim Fennell) | Action 驅動、極簡配置 (Annotation)、強大型別轉換/驗證、零 XML | 複雜表單互動、重驗證/轉換邏輯 | 多視窗長會話 (建議 JSF) | 前端簡化值得學，ActiveRecord 思想好 |
| Trails (Chris Nelson) | 領域模型即介面、零代碼生成、基於 Tapestry/Hibernate/Spring、動態驗證/i18n/安全 | 管理後台、快速原型、混合開發 (部分 Trails 部分訂製) | 高度訂製 UI、報表導向 | 非 Rails 移植，但吸收其理念 |
Struts 1 (XML) → WebWork/Spring MVC (XML + Annotation) → Stripes/Tapestry 5/Wicket (Annotation/Convention 為主, 零 XML) → Spring Boot (Auto-configuration + Conditionals)
框架無善惡，唯適不適。理解各框架「甜點」背後的設計權衡，依團隊能力、專案屬性、長期演進目標決策，才是架構師的核心價值。
