就是說jsf優于struts/webwork這類mvc框架的優勢，在于它可以與ide結合來自動生成代碼。而傳統的純手工編寫的mvc框架，影響了開發效率。因為java技術在客戶端并沒有明顯的優勢。applet已經被拋棄掉，java的強項在服務器端。sun不可能跑去使用javascript，因為在傳統開發者眼里，js只配做一點很瑣碎的任務。

于是在他們設計的這個架構中，所有的用戶事件都放在了服務器端來處理,這個決策造成了jsf致命的缺點。它把事件處理模型綁死在服務器上，限制了響應性更加靈敏的交互設計。隨之而來的網絡延遲會毀掉軟件的可用性。這也是ajax在jsf的架構中無法充分發揮作用的原因。

jsf的設計思路有點模仿vb，組件化的開發這個方向是沒錯的，ajax開發將來也會走這條路。但是jsf與vb最大的差別是vb的事件模型都是位于本地來處理的。這是一種本質上的差別，所以如果jsf確實想模仿vb，那也是東施效顰。而且在jsf的設計階段，同步的請求/響應是主流，他們的思路仍然牢牢束縛在基于頁面的開發方式上。根本就沒有思考過其他的可能。

異步請求/響應是ajax與傳統開發方式最大的差別，異步帶來了更好的交互設計。

在ajaxinaction第1章中作者舉了一個令人信服的例子。googlemaps中當用戶滾動地圖時，獲取新的地圖圖片，由于是異步請求的，因此不會打斷用戶的操作流程。而在傳統的地圖服務，每次滾動可能都需要刷新頁面。用一下微軟的那個地圖服務就可以感覺到明顯的差距，它甚至根本就不允許用戶滾動地圖。

http://terraserver.microsoft.com/

以前我說googlemaps不是ajax，因為沒有使用xmlhttprequest，這樣說看來理解有些狹隘。googlemaps請求地圖的圖片，采用的是修改動態創建的img元素的src屬性的方式，這樣的請求不會打斷用戶的操作，因此就是異步的。我們在ajaxinaction中看到作者將googlemaps當作ajax應用，而在pragmaticajax中作者說googlemaps不是嚴格意義上的ajax，兩種說法都有道理。

jsf其實如果和applet結合，可能更好些。applet是多線程的，可以捕獲用戶的操作事件，采用異步方式發送到服務器。這樣就不會打斷用戶的操作了。但是這樣一來設計的這個架構就復雜了。而且applet是已經決定拋棄的東西。jsf和javawebstart結合也可以，不過jws設計用來建造一類完全不同的web應用，即richclient，而不是設計用來建造運行于瀏覽器之內的ria應用。所以jsf最多只是一種過渡方案，在ajax/flash的競爭下早已風光不在。

未來基于瀏覽器的ria開發，ajax、flash是兩種最有前途的技術。

按照澤欣的判斷可能是三分天下，ajax、flash/flex/laszlo、還有m$的atlas。atlas是m$開發的類似于flash的一種技術，目前還只是一個vaporware，沒有看到其廬山真面目。javawebstart相比之下只能局限于一些內部應用。

將來位于客戶端的表現層開發可能會完全沒有java的位置，這是sun不愿意看到的，但是sun在這場角逐中只不過是一個小角色?！?/p>