大家为什么要用ajax开发框架(库) ?

js越简单 维护越容易 也比较容易学。

兼容性问题其实不是问题 写两份 用server判断一下客户的浏览器类型。这个方法对css也适用

为什么非要引入xslt这样技术呢，不管它千个理由……只说他不适合人类书写和思考，这就足以让我们放弃它了。
只是表现层的渲染，选择直观的模板引擎就好了，如TrimPath，客户端还选择XSLT基本上是反人类的。

选择库的问题要分开说。轻量核心库和widget库。
轻量核心库类似Prototype、JQuery这流。不说他们强在哪里，只说它们的存在实际上是一种知识的共享，它们改变你的js编程风格。自己维护库在短时间内可以在团队中保持知识的共享，但是团队变化后这种共享就会不稳定。经常可以看到新人来了看不懂前人写的js代码的问题……可是选用通用核心库的话，由于知识是在更大范围内共享的，所以它会提高团队在人员变动后造成的知识共享不畅。
而Widget库则是要改变开发模式，使用组件开发。对于网络传输不敏感的应用，他们很适合，它减少了RIA开发的关注点。

说xmlhttp封装这个问题正好可以说一下dojo。dojo的io是它的亮点之一。iframe、xmlhttp、direct source request都被封装为同样的io接口api，这可以让项目更平滑的重构。如一开始有跨域问题你用scriptSrc，然后跨小域用iframe，最后统一域后用xmlhttp，这种一致性是自己开发库比较难以达到的。这仅是一个例子，说明自己写库面临的一些问题。

我没有将xslt放到前台（只是探讨一下）

我放弃dojo的主要原因到不是感觉它有多复杂 而是感觉它太慢了。

很多ajax应用本意是给用户带来更好的体验 结果却未必如此挑剔浏览器 js错误 css错误  浏览器卡住 鼠标粘滞

流水线式的开发  要效率...

大家经验不同，导致认知不同是可以理解的。
我们用ajax框架开发效率更好，而你用xslt有最佳效率。那就各取所需吧。
至于ajax框架和你的xslt谁更好，没必要争论的。导致你放弃ajax框架的各种因素，对我们来说都是小问题，都可以轻而易举解决掉。但我们不爱看稀奇古怪的xslt代码。

我认为这个态度有问题，开发效率虽然与人相关，但是这里确实与技术本身有密切关系。否则我们可以说爱用汇编的用汇编……这个不是各取所需的问题，而是探讨一种最佳实践的问题。

对于xslt，我已经说过我的看法了。但是他说的问题也不是什么“小问题”，现有的ajax框架也不是完美的，而且具体实践更是存在许多问题。所以才需要讨论。

xslt只是一小部分 不能解决所有问题 后台还有xquery 和rhino脚本 这是不是更古怪。

用js去解决ajax框架的问题我感觉有点困难。

我尝试用xslt主要是感觉那些框架的速度太慢比如dojo。

ajax并没带来多少愉快的用户体验 经常是出力不讨好。

而当我直接用xmlhttp结果却出人意料的快， 所以我觉得ajax向胖客户端发展完全是被美工和交互设计人员误导了。

商业应用根本不需要这些华而不实的东西 广告娱乐业需要的微软的sl和flsah类的应用 ajax本身更适合瘦模式 在这个模式下它能充分发挥速度和交互的优势 同时简化了web开发。

在我看来你所说的几点都值得商榷：你提到的ajax框架的问题，在我看来更多的是这些框架本身不成熟的表现，完全不成为你打倒“胖ajax”的论据；用js解决有点难，是不是你自身js能力的问题呢；至于你前面所提的开发效率问题，虽然目前js开发确实还存在一些困难，但实在没理由认为xslt会提高效率。

最后，在我看来商业应用最终同样需要良好的用户体验。但即使internet应用也请不要把用户体验与满世界的拖拽和黄褪等同起来。

第一个，现在如dhh所说，确实还没有充分挖掘出js的潜力。其次dojo慢不代表所有的框架都慢。这需要一定时间的改进，例如我写的js log框架就比其他log框架要快一些（先自我吹嘘一下）。。。

ajax确实不等同于好的用户体验。因为好的用户体验主要来源于好的交互设计。技术是起到实现和支持其设计的作用。缺乏设计，就算用flash/sl等最新的最cool的产品，也一样失败。

提高用户体验，是要落到实处，是要以用户为中心。商业应用不一定需要非常cool的效果，例如半透明、拖拽等等，他首先关注实际功能、稳定性等，确实如此，但是不代表用户体验就不重要，如果上述特性确实可以改善产品的可用性、提升客户的效率，那当然就有用。