JSF 誕生邏輯與架構缺陷根源
- 組件化開發趨勢：自包含組件利於 IDE 視覺化拖拉生成，提升效率 → JSF 優於 Struts/WebWork 的理論優勢
- Java 客戶端失利：Applet 被棄，Java 強項在 Server 端 → Sun 拒絕 JavaScript（當時視為「瑣碎玩具」）
- 決策錯誤：所有用戶事件**強制在 Server 端處理** → 事件模型綁死於 Server，網路延遲成倍放大，毀掉可用性
為何 Ajax 無法在 JSF 架構中發揮作用
- JSF 生命週期、狀態管理、元件樹全部建立在**同步請求/回應**基礎上
- 異步請求/回應是 Ajax 與傳統模式最大差異，帶來非阻塞交互
- JSF 設計階段同步為主流，根本未考慮異步可能
Google Maps 案例：異步交互的說服力
- 拖曳地圖 → 異步載入圖塊 → **不阻塞用戶操作流**
- 傳統地圖服務：每次拖曳整頁刷新
- 微軟 TerraServer：甚至禁止拖曳，只能點擊方向鍵
Google Maps 雖未用 XMLHttpRequest（改用動態 img.src 觸發請求），但**本質是異步**，不阻塞 UI 線程，符合 Ajax 精神。
JSF 模仿 VB 卻忽略本質差異
- VB 事件模型：**本地處理**，零網路延遲
- JSF 事件模型：**遠端處理**，延遲不可控
- 東施效顰：形式神似，實則背道而馳
歷史包袱與出路
- JSF + Applet：技術可行但 Applet 已棄，架構複雜度爆炸
- JSF + Java Web Start：定位 Rich Client（桌面級），非 RIA（瀏覽器內）
- 結論：JSF 只是**過渡方案**，在 Ajax/Flash 競爭下光環褪盡
未來 RIA 三分天下
- Ajax（開放標準、生態最豐）
- Flash/Flex/Laszlo（運行時一致性強、多媒體優勢）
- Microsoft Atlas (後為 Silverlight，現已停更)
Java Web Start 侷限於內部應用。瀏覽器端表現層未來將無 Java 立足之地，Sun 在這場博弈中只是小角色。
