Sun為什麼會搞出一個JSF，JSF為什麼會是現在這個樣子，我想原因是這樣的: 首先，基於組件的web開發將來會是一個趨勢。自包含的組件便於IDE的處理，可以提高開發效率。 就是說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與傳統開發方式最大的差別，異步帶來了更好的交互設計。 在Ajax in Action第1章中作者舉了一個令人信服的例子。Google Maps中當用戶滾動地圖時，獲取新的地圖圖片，由於是異步請求的，因此不會打斷用戶的操作流程。 而在傳統的地圖服務，每次滾動可能都需要刷新頁面。 用一下微軟的那個地圖服務就可以感覺到明顯的差距，它甚至根本就不允許用戶滾動地圖。 http://terraserver.microsoft.com/ 以前我說Google Maps不是AJax，因為沒有使用XMLHttpRequest，這樣說看來理解有些狹隘。 Google Maps請求地圖的圖片，采用的是修改動態創建的img元素的src屬性的方式，這樣的請求不會打斷用戶的操作，因此就是異步的。 我們在Ajax in Action中看到作者將Google Maps當作Ajax應用，而在Pragmatic Ajax中作者說Google Maps不是嚴格意義上的Ajax，兩種說法都有道理。 JSF其實如果和Applet結合，可能更好些。Applet是多線程的，可以捕獲用戶的操作事件，采用異步方式發送到服務器。這樣就不會打斷用戶的操作了。 但是這樣一來設計的這個架構就復雜了。而且Applet是已經決定拋棄的東西。 JSF和Java Web Start結合也可以，不過JWS設計用來建造一類完全不同的Web應用，即Rich ClIEnt，而不是設計用來建造運行於浏覽器之內的RIA應用。 所以JSF最多只是一種過渡方案，在Ajax/Flash的競爭下早已風光不在。 未來基於浏覽器的RIA開發，Ajax、Flash是兩種最有前途的技術。 按照澤欣的判斷可能是三分天下，AJax、Flash/Flex/Laszlo、還有M$的Atlas。 Atlas是M$開發的類似於Flash的一種技術，目前還只是一個vaporware，沒有看到其廬山真面目。 Java Web Start相比之下只能局限於一些內部應用。 將來位於客戶端的表現層開發可能會完全沒有Java的位置，這是Sun不願意看到的，但是Sun在這場角逐中只不過是一個小角色。
