AJAX & JSF

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中当用户滚动地图时，获取新的地图图片，由于是异步请求的，因此不会打断用户的操作流程。
而在传统的地图服务，每次滚动可能都需要刷新页面。
用一下微软的那个地图服务就可以感觉到明显的差距。
以前我说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/Lazso、还有M$的Atlas。
Atlas是M$开发的类似于Flash的一种技术，目前还只是一个vaporware，没有看到其庐山真面目。
Java Web Start相比之下只能局限于一些内部应用。
将来客户端和表现层的开发可能会完全没有Java的位置，这是Sun不愿意看到的，但是Sun在这场角逐中只不过是一个小角色。

Ajax Patterns and Best Practices的作者有个观点,

但是我不能接受这样的论点，即，一个服务器端框架是开发Ajax应用所必需的。

我不想引起争论,等着看吧.
我的观点是开发设计ajax与服务端设计是松散耦合的,或 没有web服务器可以开发ajax,如AJAX+SOA.

JSF与ajax结合是个麻烦恶心的事情.

个人觉得AJAX这样的技术应该能更方便的让更多的程序员或者非程序员来使用.
让普通人能作出不普通的事情,JSF是一个不错的途径.

前途漫漫啊！
myfaces的不少组件就是取自dojo。
照这样看来，JSF只能封装现有的ajax框架，也不可能自己实现客户端UI或库。如果这样干如GWT，google先做好客户端拖拉......复杂的脚本，然后再封装到服务器组件中。我还不如自己调用客户端类库呢？

jsf和webwork2.0位置差不多。但webwork2.0封装的dojo让人（我）呕吐。

在arcgisserver领教过，用jsf/asp.net服务器控件实现类似ajax的东西。地图控件。如果想改改控件的，灾难啊。

http://www.esri.com/software/arcgis/arcgisserver/