canonical

   JSF(Java Server Faces)技術從發布時間上看已經是一種比較古舊的技術了，但是目前仍未能成為主流的開發實踐。從我知道這種技術開始, 我對它的判斷就與我最早對于EJB的判斷一樣, 它們都在某種程度上捕獲了真正的需求,但是因為它們自身詭異的技術路線.我很懷疑是否這些標準制定者故布疑陣, 便如Microsoft的OLE技術一樣, 故意拋出一個錯誤的方向, 將大批組件開發商帶入死局.
   JSF技術是一種雙重的存在：它首先是一種標準，然后也提供了一種缺省的實現。但是從這兩方面，我都無法看到JSF的未來。
   從設計上說，強類型的視圖模型對象層與Witrix的架構設計原則嚴重沖突。Witrix的基本架構是瀏覽器和后臺服務器通過具有顯明語義的url實現兩分，這也是所謂REST風格的一種內在要求。隱蔽了鏈接的技術破壞了基本的web超鏈模型. 為了獲得那么一點點結構控制能力, 做出這樣的抽象是不合適的.JSF的配置模型繼承了structs的傳統，仍然是那樣的冗長繁雜。我們是否真的需要這些配置文件，還是希望像ROR那樣在代碼中直接完成一切？
   不能在標準的瀏覽器中預覽. 可以說創造了一個JSF IDE的市場, 但是這無疑是一個無聊的市場. 現在有一些備選的方案, 如Facelets, 使得jsf可以采用屬性語法, 但是只要想想僅僅為了這么一點小小的修正所需要付出的開發量就足以讓人崩潰。
   JSF提供了組件級別的事件響應機制，因此似乎是AJAX應用的理想場所．但從Witrix平臺的開發實踐來看，JSF對于AJAX的使用是受限制的，有著很大局限性的．組件事件響應并不一定要采取JSF那種體系結構．
   從實現角度上說，基于jsp tag可以說是JSF的致命弱點之一. jsp tag從設計之始就一直是未經過實踐考量，其設計無法支撐復雜的控件架構. 特別是早期JSF與標準的JSP tag不能互通實際上是明顯的設計缺陷, 而且性能問題是內置在該設計中的. 現在雖經多個版本的不斷補救, 但是為了兼容性, JSP Tag負擔過重, 它始終是基于文本處理模型，實際上不可能有什么本質性的進步.　JSP tag模型過分孱弱必然造成JSF設計中大量處理過程堆疊到界面對象層，更加劇了JSF的模型復雜度和性能瓶頸。 實際上根據Witrix平臺中tpl模板技術的設計經驗，大量界面構建過程是可以在模板層以直觀的方式完成的，而不需要借助視圖模型對象。
   所有問題的一個集中體現就是增加一個新的JSF組件絕對不是一件平凡的事情．如果有一天這個問題可以得到解決，那時的JSF從思想和實現上都必然和現在的JSF有著本質性的區別．