假如我确实喜欢HTML、CSS和JavaScript又将如何？

其实Ajax和REST在性能和可伸缩性方面的优势要在高并发的场合下才能显示出来，这也是面向Internet的Web应用常见的情况。对于普通的面向Intranet的企业应用来说，因为并发量小，不会对服务器造成很大压力，所以感觉不到Ajax和REST在上述两方面的优势。

Ajax、REST、RIA的基本思想就是把服务器端做的一些与表现有关的逻辑分摊到客户端去做，最理想的情况是服务器保持无状态，这样可伸缩性最好。但是这些优势都是要在高并发的情况下才能显示出来。我们肯定要首先保证服务器的性能和可伸缩性，然后再考虑优化客户端应用的性能。如果服务器因为高并发都已经无法提供服务了，那么客户端性能再好也没有价值了。

现在服务器端压力比传统瘦客户端小n倍 根据应用不同会有变化。

至于客户端处理比重的问题和瘦客户端没有关系。 如果大家的浏览器都支持xform 我就解放一部分服务器端的处理 这是可伸缩的。 现在浏览器什么都不支持我就全部由server端提供dom节点   

这里似乎有一点自相矛盾（回归CS喽），因为DHH同志曾经讽刺offline应用只在plane上有用……当然我认为他也就是开开玩笑。

这正是server端方案的问题所在。你不要说你跟jsf有什么差别。jsf就是这个思路。不过就是以前它没有用ajax么，但是现在老袁同志已经把它改成ajax inside喽。

过去我看到有个xul社区的人批评jsf就是：客户端有一颗状态树，服务器端就会维护一个状态树副本。有状态和无状态的差别是相当的大的，更何况你在服务器端是保留若干个巨费的dom树。我算你一个dom 1M，你考虑一下100000用户在线的情况？

如同dlee说言 rest是分布的 可缓存的。 hax你也熟悉cocoon。cocoon不用dom。 cocoon的缓存机制十分精良 每个uri的内容都有很好的缓存。而且我说的瘦客户端后台 即包括rest也包括采用post的类soap方式 他们的共同点就是将缓存分布在整个网络的所有服务器上。 

服务器端不维护任何状态 当ajax请求数据时 server端只返回数据  只是数据的输出由xslt自由转换而已。如果用css直接能将xml数据正确显示出来那么数据也可以直接交给ajax 不经过xslt

难得有这么多高手在场

客户端存储方案和瘦ajax模式根本不冲突。

瘦ajax依然是ajax可以获得离线存储方案带来的所有好处

hax说的太对了。JSF最大的问题是它的可伸缩性很差。用来做并发量不大的企业应用还可以，用来做并发量非常大的Web应用是不可能的。Ajax火了，JSF就添加一点Ajax组件，宣称完美地支持Ajax；REST火了，JSF就添加一个支持REST的规范（JSR 134），宣称完美地支持REST。Sun企图以不变应万变，这个策略是荒谬的，问题就是我们根本就不需要JSF，我们有更好的解决方案。

hax还记得以前有个Enhydra XMLC的方案吗？也是同样在服务器端维护一棵与客户端相同的DOM树。XMLC现在已经完全被人遗忘了。

说的太多了。 语言的作用有限

就象我前面说的关键是行动。

可能相关的实践只有我尝试了。 我一说到什么 大家就凭借自己的经验联想到一些东西 其实根本就是两回事

我现在正在用这个技术策划一个规模和访问量比较大的项目 我一个人做啊 估计1个月后能上线。  那些自认ror很圆的可以等等看 毕竟1个月时间不长

to winterwolf：
我也不认为你所鼓吹的瘦ajax有什么前途，dlee的论据很充分。事实上，我在实践中也感到采用类似服务器端生成Dom的方式，我自身的工作量没有减少。你不妨做个代码分析，比较一下两种模式，否则你的论调很难被别人接受。

  我保持沉默

一个月后再谈这个话题