REST+RIA方案

关于HTML，我表达的意思和你的意思有矛盾么？


但是俺不同意你的CSS/JS/DOM Hack论。HTML创造之初就有stylesheet的概念，只不过不是CSS。用于SGML的样式表是DSSSL。

“浏览货品列表”，“购物车”和“结帐”是三个独立的页面，但是你不是一样把他们都堆积到一个swf文件里了么？我觉得我们说的都不矛盾，只是在架构的组织上看法不一样而已。

从编程体验来说，虽然我没有用flash编写过程序，但是我相信由于flash vm的统一，以及有一个好的IDE，所以flash相对来说要比编写js来的爽快的多。

你说的rsl技术，我不知道是什么，你看到的是重用的好处，而我看到的是延迟加载，也就是说只有客户端真正需要的时候才传给客户端。

我个人的看法，xslt是“向正确的方向迈出的错误的一步”。服务器生成XML格式的数据，浏览器根据XSLT转换为界面，这个思路和REST已经很接近。但是界面上的问题并不适合完全用XML来解决，那个时候人们太迷信XML是万能药了。

我认为，这个问题的答案应当看具体环境。在一般网络情况下，ajax比较合适，因为它整个过程中负荷比较均衡，不像单次加载开始的时候需要明显的延迟。但是如果带宽足够，特别是局域网中，一次性加载也有一些优势：（1）可以极大减少请求次数；（2）服务器可以不用再考虑缓存页面的问题；（3）用户体验更加连续，不像Ajax经常出现轻微的停顿；（4）可以避免偶然出现的网络错误造成可用性的急剧下降。

完全同意。





在这个问题我认为该批评W3C，它们早期推行Web标准极为不得力，又不会为开发人员着想，反而要让程序员为它们的东西收拾烂摊子。






虽然是在同一个swf文件中，但设计的时候仍然是分开三个文件来设计的，这就是差别。有点类似于写一堆.class文件，然后让java为你打包成一个JAR一样的意思。

技术本身应该是中立的 错误的使用必然会事半工倍。

如果你愿意我们可以对比一下shoping的设计和代码 及开发速度 运行效率。

rest + xslt +xmlhttp 的开发速度和灵活性和用户体验应该高于ria

区别

rest后台
RIA 后台 rest 只提供原始数据（json or xml） no view

瘦ajax   rest只提供原始数据(xml)  外部xslt资源提供view服务  外部webservice资源提供 数据聚合 ws调用 

前台
RIA  支持多媒体 动画 及3d 。 对客户端要求较高
瘦ajax 无延迟图文交互。 客户端可运行xmlhttp js即可 css可有可无

开发方式
ria 基于传统ide开发工具
瘦ajax  基于blog 或者 wiki 无需本地ide

你这个比较有很多问题，或许你拿一个具体的案例还比较有说服力。

不是那个时候人迷信的问题。

主要的问题是xlst并不能保证你分离内容和样式。反而会倾向于把html作为presentational语言。如果xslt中包含了操作内容的js，那更是混乱之源。

(1)
a. 合理的模块规划下，第一次访问的次数也会被控制的很好。合理缓存后，下一次的首页访问中有许多可以直接用缓存而不会产生请求。
b. 服务器开启keep-alive支持，这大大减低了多次请求的延迟。
c. 浏览器和服务器开启http pipeline支持（opera默认开启，ff需要设置，ie不支持），多次请求可被合并到连续传输中，这种情况下请求次数基本不成问题。

总的来说，请求次数少的优点有限，而且未来这种优势会越来越小接近于0。

(2)
为获得良好性能，考虑如何合理使用缓存是必然的。这也是REST的特点。

(3)
通讯停顿可以通过智能的预取来缓解。如果有必要的通讯延迟，则flash和ajax是没有区别的。区别仅仅是，在flash下，通常可保持动画平滑（以更大的cpu占用率为代价），而ajax动画乃至浏览器的一般响应，在机器负荷较大情况下，会出现迟滞。

(4)
这取决于设计和实现的完备性，与采用ajax或者flash没有直接关系。

你批错人了。早期是浏览器为了互相争夺用户，而盲目推出未经良好设计的新功能。罪不能怪在w3c上，都是浏览器厂商的问题。尤其是IE在竞争中获胜后，MS背弃了web开发者，背弃了遵循标准的承诺。直到ff重新成了有力的竞争者，MS才对自己的产品做了一些改进。