AJAX与RIA技术之我见

DHH于6月底曾经发表过一篇文章，名为《我就喜欢HTML/CSS/JavaScript，那又怎么样！》，大意是说，目前热炒的RIA技术并不能够取代AJAX技术，而事实上我们还没有发挥出HTML的全部潜力，我本人很享受HTML/CSS/JS给给我的开发体验云云。

我比较赞成DHH的观点，从另外一些角度谈谈我对RIA技术，主要是Flex的看法。

我在2004年曾经指导一个企业应用系统的开发，这个系统提出了比较高的实时反馈和交互式要求。由于同时有两个flash高手加盟，我们决定采取基于flash的RIA技术：

对于交互要求非常高的部分使用flash开发，flash通过AMF协议和服务器端通讯，服务器端使用了OpenAMF这个开源框架，可以解析AMF请求，转化为对Spring bean的调用，这个架构是一个标准的分布式系统调用：

flash <-----AMF-----> OpenAMF网关 <--> Spring Ioc

和现在很多人普遍采用的AJAX DWR框架是一个道理：

IE <-----XHR-----> DWR <--> Spring Ioc

客户端的flash是先用Flash IDE画好界面元素，保存为fla文件，然后程序员使用ActionScript编写代码，和服务器端进行交互。这是一个标准的基于Flash的RIA方案，但是项目最终放弃了Flash RIA。

时至今日，REST+Flex又被作为一个非常热门的方案被提出来了，那么REST+Flex比2004年我们采用的AMF+Flash方案有什么区别呢？

一、服务器端和客户端交换数据的方式不同

1、AMF+Flash采用的是标准的RPC方式，这种方式的被广泛的使用在EJB，XML-RPC，DWR等等，这种方式的缺点这里不赘述了，JavaEye以前有大量的讨论

2、REST+Flex采用的是REST方法，这种方式是现在非常热门的轻量级分布式系统解决方案之一，优点也不赘述了，JavaEye也有大量讨论

二、客户端描述界面的方式不同

1、AMF+Flash采用标准的Flash IDE来画界面，保存为fla后缀的二进制文件，界面文件不可直接用文本编辑器编辑，一般程序员很难使用。

2、REST+Flex采用Flex Builder来画界面，或者用文本编辑器手工编写MXML，这是一种带有namespace的XML的文件，程序员比较容易使用。

通过比较我们可以发现，REST+Flex的方案已经前进了一大步，但是我还没有提到为什么2004年那个Flash RIA方案会失败，为什么呢？失败的最重大的原因在于开发成本！

你会说，我们用AJAX开发成本也很高阿，HTML/CSS/JS跨浏览器兼容性的成本非常高。Flash不用考虑跨浏览器，界面还可以用IDE直接画，AS代码和MXML界面彻底分离，多棒的MVC，开发效率怎么想都比AJAX低很多。不错，Flash没有跨浏览器开发成本，但是Flash有一个巨大的和网页交互的成本。

这又牵扯出来一个更深层次的问题：互联网传播的主要载体是什么？文本？图片？视频？还是其他的什么？

HTML的诞生是适应于互联网大量文本内容的传播的，只要你的web应用还是以文本为主，就必须以HTML为主，这一点无法改变。那么就意味着你的Flash RIA必须要大量的和HTML页面进行交互。(也有一些纯网络游戏或者休闲游戏网站是纯flash的，几乎没有HTML，但这不是我们讨论之列)

所以问题就在于Flash和网页的大量交互，但很遗憾的是Flash操纵网页DOM的能力很弱，与传统的JavaScript无法相提并论！所以你会遇到各种意想不到的问题，而这些问题原本用JavaScript却是很简单的事情，例如驱动网页导航，刷新，打开关闭窗口，DIV隐藏显示等等，开发成本就是这么不知不觉升上来的。最终你会发现Flash的开发成本太高！

其实这不能怪Flash，根源在于：你开发的web应用最终还是一个基于文本形式的，所以你就无法使用纯Flash应用(Flash对于文本支持能力又很弱)，必须大量依赖HTML；而要大量操纵HTML，最趁手的工具就是JavaScript，而Flash就是一个很蹩脚的工具，无论它的多媒体表现能力多么强大。

SilverLight能改变这一点吗？不能！Microsoft发明XMLHTTP绝对是天才的创意，XMLHTTP之所以成功根本原因在于它和HTML的良好交互性，而且使用JS操纵。SilverLight只是Flash的一个模仿品，却完全没有看到Flash的局限性在哪里？所以SilverLight完全继承了Flash的致命缺点。这也只能说明SilverLight是Microsoft商业竞争的一种手段，而不是本着创新精神去做的东西。

现在开发AJAX的确有其痛苦之处，跨浏览器兼容性是最让人头疼的。但是我们应该清楚，只要web应该是基于文本形式这一点不改变，那么HTML/JS的地位就不会改变，那么AJAX无论如果都是web开发之首选技术。

评论

28 楼 neuhawk 2007-08-10  

silverlight是否成功,要看是否实现wpf的功能

27 楼 lordhong 2007-08-10  

做了一个flex+j2ee的项目, 非常看好flex前景.
apollo和flex3都出来了, adobe的前景我很看好.
ms的silverlight是很明显冲着flex来的.  PC上的应用我不看好, windows mobile上的可能会比较有意思, 可以看看这个silverlight在WM上的MLB demo: blogs.msdn.com/mikehall/archive/2007/05/03/medc-2007-sliverlight-on-windows-mobile.aspx

不过adobe也在做flex的mobile版本, 目前是flashlite和flashcast占主角, 但flex mobile应该很快就来了.  WM上很有可能就不支持adobe的产品了, 直接推silverlight mobile了. =]

26 楼 lwz7512 2007-08-10  

头一次看见老大robbin对RIA发表看法，机会难得啊，我也来说两句：

1。首先讲讲楼主谈到项目的时代背景
在2004年是众多flash设计和开发人员以flashmx/flashmx2004为工具的年份，当时的flashplayer版本为7，flash虽然火爆，但是停留在设计广告、片头、宣传片、演示、个人网站、个性化的产品网站、小游戏等等层面上。本身就flashmx/as2/flashplayer7这样的工具，应该说它还只是“设计人员”的吃饭家伙，如果让它来承担“比较高的实时反馈和交互式要求”这样的任务，本身就是“不可能的任务”或者说是风险很大很大的，虽然说也能实现实时性和丰富的交互体验，但是很可能不能满足企业级软件的要求，失败也就变的正常了。RIA的概念在2004年才刚刚提出来，flex1.0才刚刚推出，还稚嫩的很，用flashmx来做企业应用那简直就是吃螃蟹。

2。接着在讲讲Flash RIA的开发成本
“Flash有一个巨大的和网页交互的成本”这在2004年是成立的，因为flash的外部接口(ExternalInterface)是在2005年flash8发布时才增加的功能，如果没有这个接口，as<--->js之间的通讯是不可能的。如果有大量交互的话，那真应该反思一下设计，这种方案是否有问题，当然现在这种需求技术上是没有任何问题的，比如google finance ,yahoo finance 。flash/flex RIA的开发成本目前来说，一点都不高，应该是低于j2ee的，高于ROR的，技术层面没有瓶颈问题，人力成本也不是很高，一个flash/flex程序员的工资比j2ee程序员的工资高不了哪去。

3。然后讲讲flashIDE与开发效率
flashmx/flashmx2004/flash CS3严格来讲都属于设计工具，如果用它来做产品的原型设计，网站原型设计，界面设计都是很合适的，我就是非常喜欢用它们来画界面，现在的flashcs3绘图功能又增强了许多，与photoshop/flex3的完美协同工作(官方叫工作流)也是前所未有的，不能用开发工具的要求来要求他们，更不能用“一个很蹩脚的工具”来形容它，企业级RIA的开发应该由flexbulider来承担，它才是正儿八经的IDE，用过它的人都知道，它是基于eclipse的，除了收费这点让我们不爽，其他还是可以的，但是它离专业的java开发工具还是有差距的，比如代码重构、自动生成、代码查找、性能评估(profiler)、增量编译等方面，毕竟这个工具是2005年adobe接收(以前是macromedia的产品)过来重新改造的产品，要给人家时间吗。

4。之后讲讲html应用_PK_flash应用
不管是走公网的应用还是企业内部应用，如果是要表现文本信息或者再加个图片什么的，普通html页面就可以做的很好，如果硬要用flash来做自己不擅长的东西，反过来说flash不好，那可真是冤枉了。在flash9/as3以前的时代(2006/06以前)，flash内容的基础构成是movieclip以及符号，完全是针对动画和多媒体来设计的整个架构(包括flashplayer)，而到了swf9/as3/flashplayer9的时代(adobe财大气粗的结果)整个架构才完全改变，整个平台发生根本转变，flashplayer的虚拟机AVM2脱胎换骨，更快，flash的单元构成也不再是电影片段，而是显示对象(displayobject/sprite)这样更具有扩展性的东西，然而由于flashplayer的特殊性，其渲染文本的性能还是比不上浏览器。所以，做web应用就必须定位好它的内容、受众、发布渠道，能用html做好的，就别让flash来做，html做不好的或者做不了的让flash来做。为什么互联网上的flash应用比较少，是因为多种因素造成的，比如带宽限制、文字信息主体性、用户习惯等等，而在企业内部的应用，一些以数据、图形为主的应用flash绝对可以胜任，而且能大显身手。

5。最后杂七杂八讲点
以flash/flex为代表的RIA技术正在不断进步，以前根本不敢涉足的门户(portal)、报表、商业智能(BI)等领域都会有所成就，比如说flex的module为widget/portlet做好了技术准备，而flex3的高级表格也为报表功能提供了基础。在企业web应用方面，flash/flex绝对可以大显身手，让我们有更多的选择和惊喜。silverlight(formerlly WPF/E)虽然正式推出时间不长，但是其定位是明确的，移动设备以及高清视频、3D图形等方面，它的市场策略应该是针对flash，但是要比flash还要高端一些。这里再拍一下dlee的马屁，李老师说话还是很中立的，而且每次说话都论据充足、翔实，对flash的态度比较积极。

一不小心，说了这么多，不好意思。

25 楼 hax 2007-08-06  

sp42 写道

hax 写道

sp42 写道

Javascript的再激活，除了在客户端上参与和(x)html的复兴外，亦正在驾临服务端的开发。参见一则消息：

说点题外话，你这个句子，怎么觉得那么别扭，难不成你正在学日语？ ;)

根本不别扭。

看来我无法体会渠的中文境界和意境了。。。

24 楼 blackanger 2007-08-05  

综上所述：不矛盾。

23 楼 kldwq2002 2007-08-05  

个人觉得，没有可比性。

22 楼 sp42 2007-08-05  

hax 写道

sp42 写道

Javascript的再激活，除了在客户端上参与和(x)html的复兴外，亦正在驾临服务端的开发。参见一则消息：

说点题外话，你这个句子，怎么觉得那么别扭，难不成你正在学日语？ ;)

根本不别扭。

21 楼 dlee 2007-08-04  

Adobe早就充分认识到了基于Flash的RIA技术不可能取代基于HTML的技术。他们的策略是与Web标准充分合作，希望将这两种技术无缝地集成在一起，取长补短。他们最新推出的AIR允许开发人员自由选择使用何种表现技术：
1. 仅使用DHTML
2. 仅使用Flash
3. 使用DHTML+Flash

M$两年前的策略是以WPF/XAML来取代基于HTML的技术（Windows取代浏览器），这是他们与Adobe最大的区别。最近M$也发现实现这个目标力不从心，所以他们通过大力发展Sivlerlight，走上了与Web标准合作的道路。

另外一个主要的区别是，M$出于私心，不会认真支持服务器端ASP.NET之外的其他开发平台。使用服务器端的其他开发平台，如果选择M$的RIA技术，开发效率会大打折扣。而Adobe的RIA技术则是服务器端开发平台中立的，目前看来Adobe在继对Java的支持之后，会大力推动Flex与Rails的结合。

浏览器对Canvas/SVG目前的支持还比较初级，需要经过高层的抽象，发展出一些功能强大的Widget组件库之后才好在项目中大规模应用，否则开发效率太低了。这个过程可能还要再等上两年左右。而Flex是已经发展了3、4年的成熟技术，所以对于特定的复杂交互需求，现在选择Flex是一个正确的决定。

20 楼 hax 2007-08-04  

dlee的这个消息有点老。我来做点更新：

whatwg已经成功说服w3c，所以w3c已经重新启动html小组（http://www.w3.org/html/），把webapp1(html5)纳入官方规范流程了。这个也是必然的，看看whatwg的组成就知道了，mozilla, apple, opera，再加上整个Spec的编辑Ian Hickson是google的（原来好像是opera的人），除了微软之外，所有的主要浏览器厂商外加一个webapp的老大，都齐全了。而微软现在也已经加入了开发（至少看到他们的老大在ml中的帖子鼓吹增加html version机制）。

那么xhtml2摆在什么位置？我现在还不能完全确定，虽然webapp自己说俺们和xhtml2不同的，但漏出来的xhtml5的名字已经摆出了狼子野心。我还没有仔细看w3c的Architecture说明的更新，但是想来也是打打马虎眼，说两者的field不同，xhtml2/xforms等归于enterprise方向了。

其实我是很喜欢xhtml2/xforms的。。。当然，我也很喜欢webapp，因为其确实弥补了好大的空白。

虽然浏览器的反微软阵营已经结盟（当然嘴巴里不会承认），但是他们与ms有一点相同，就是强调向前兼容（微软老是拿这个当作陈词滥调），因此希望一种渐进式的方式，mozilla的cto也是js之父的Brendan Eich同志就表达过对xforms的不同意见，而opera的人有时候也会有点奇谈怪论（例如很久以来死活不支持xslt直到opera9才支持，最近的如不肯支持js的get/set扩展）。

回过头来说ms，ms现在已经加入html wg，毕竟他还是浏览器的老大（这是moz,opera,apple都承认的），是w3c的很重要的成员。它参与标准开发是没有问题的，问题在是否支持，支持多少上。过去有些标准都是ms的人主导的，但是回过头来他们自己居然不支持，或者扔出个个草案实现就没动静了。而且ms的人还经常有一些荒谬的理由扔出来，例如说css和dom没有足够好的官方testsuite，所以他们就不实现。

显然，所有动作都要根据ms的商业利益来考虑，这是赤裸裸的真理。但是毕竟moz,opera,apple加上goolge的结盟绝对是很有分量的，前三者的浏览器市场份额总和应该有15%以上了。特别是apple的来势汹汹，iphone上都要有safari，加上windows版的safari，其战略颇像ipod加windows上的itunes。再加上一个最最厉害的web应用厂商google……ms明白不合作是不行的，不如加入进去，想法获得主导权。

浏览器厂商和adobe的关系也是很奇怪的。

ms跟adobe的竞争是很显然的。silverlight咋看咋是针对flash来的。

而moz跟adobe有很好的合作，特别是在es4上面，adobe甚至把js vm的源代码都送给moz了（当然不是白送，而是一起继续开发）。但是显然超强的Web browser与ria有竞争关系的。比方说具有完全canvas/svg支持的浏览器上，dlee举的照片处理的例子也应该可以实现。

也许adobe想把未来的前端融合起来？反正我是没搞明白adobe的战略。

19 楼 hax 2007-08-04  

sp42 写道

Javascript的再激活，除了在客户端上参与和(x)html的复兴外，亦正在驾临服务端的开发。参见一则消息：

说点题外话，你这个句子，怎么觉得那么别扭，难不成你正在学日语？ ;)

18 楼 sp42 2007-08-04  

Woo Yeah Yeah 和群众的声音不谋而合！

引用

【D群讨论精华】：Ajax、Flex并不矛盾。

江上浪 10:24:38
用哪种好呢
我就是没细胞 10:20:36
第一个 是不是 后两个运行的环境啊
奋斗是硬道理 10:20:43
其实跟extjs是差不多,只是技术不一样
  江上浪 10:21:46
跟flash的脚本有什么联系吗
我就是没细胞 10:21:57
肯定有

  江上浪 10:22:15
那开发工具有吗
Yのo翔メ云 10:22:33
ria的两种方式，我觉得都不错
奋斗是硬道理 10:22:33
在用flex2开发,要用它的script写
Yのo翔メ云 10:22:52
奋斗，你会Flex？
奋斗是硬道理 10:23:14
正在学习,已经跟spring进行整合了
  江上浪 10:23:29
以后用ext就可以写了
我就是没细胞 10:23:36
 
我就是没细胞 10:23:40
 
我就是没细胞 10:23:49
发错了``原谅下哈 
奋斗是硬道理 10:23:58
两种技术我都在关注
我就是没细胞 10:24:09
天哪  我jsp 还要复习一下哦 
Yのo翔メ云 10:24:25
Flex 也可以跟PHP结合的
奋斗是硬道理 10:24:28
extjs比较轻量级
奋斗是硬道理 10:24:56
用好了,都好
Yのo翔メ云 10:25:01
一般的使用我觉得extjs好
奋斗是硬道理 10:25:23
flex2不用考虑浏览器问题
Yのo翔メ云 10:25:36
开发大型的交互式社区，我觉得flex好

  江上浪 10:25:51
那要用单独的客户端呀
Yのo翔メ云 10:25:53
http://www.1001m.com/
奋斗是硬道理 10:25:59
我感觉flex2目前比较适合写应用
奋斗是硬道理 10:26:26
局域网的跟好
Yのo翔メ云 10:26:51
呵呵！是呀!技术都是好的，看我们用在哪，怎么用
  江上浪 10:27:13
如果结合起来做web游戏怎么样
奋斗是硬道理 10:27:16
是的
奋斗是硬道理 10:27:22
也不错
Yのo翔メ云 10:27:25
完成可以哦
  江上浪 10:28:27
有没好一点的flex的中文网站，先了解一下
Yのo翔メ云 10:28:45
哈哈！可惜我们这边网络发展水平太低，给客户做这些东西，他们也当垃圾！
  江上浪 10:29:12
怎么不换个地方发展或
Yのo翔メ云 10:29:36
算了，懒人，喜欢悠闲的生活
奋斗是硬道理 10:30:14
呵呵
Yのo翔メ云 10:30:33
技术是学着自己玩的，哈哈！
  江上浪 10:30:47
http://labs.flexcoders.nl/samples/PageFlip/001/
Yのo翔メ云 10:31:01
奋斗，学JAVA有什么好的推荐入门书籍？
&Artkai 10:31:26
Yのo翔メ云 ， 同道中人啊~~~！！o(∩_∩)o...
  江上浪 10:31:32
flex是什么推出来的或
Yのo翔メ云 10:31:38
好久了
Yのo翔メ云 10:32:00
已经出了好几个版本了嘞
奋斗是硬道理 10:32:00
java入门书?我一时也想不出来哦
Yのo翔メ云 10:32:24
哦！还在写PHP哈哈，得换换代了！
奋斗是硬道理 10:32:35
flex到第二版才可以进行应用开发,前面都是不完善的
  江上浪 10:32:37
flex3也出来了
&Artkai 10:32:39
flex 是不是要装flash player 9 才能用？？？
Yのo翔メ云 10:32:47
　&Artkai
奋斗是硬道理 10:32:57
现在flex3也出来了,且apllo也推出了
Yのo翔メ云 10:33:06
好像还有个apllo的概念吧！
Yのo翔メ云 10:33:20
flex要脱离浏览器了　
奋斗是硬道理 10:33:23
是的,adboe野心很大啊
Yのo翔メ云 10:33:31
嗯！要成为桌面的了
奋斗是硬道理 10:34:13
是的,他的目标是桌面跟WEB将来是不分家了,
Yのo翔メ云 10:34:31
嗯！有前景的
奋斗是硬道理 10:34:37
断线就是桌面应用,上线就是WEB应用
  江上浪 10:35:01
本来web应用程序就越来越受欢迎了
Yのo翔メ云 10:35:15
是呀！所以咱们也都要跟上时代哦！嘿嘿
  江上浪 10:35:29
但要学的东西也太多了
奋斗是硬道理 10:35:41
做这一行,就是这样啊
Yのo翔メ云 10:35:44
没办法的！江，你ext怎么样！？
  江上浪 10:35:58
刚学了一个月左右
我就是没细胞 10:36:04
先放着 以后再说吧
╁蓝驿┲→ 10:36:28
顶下
&Artkai 10:36:36
那现在用flex 做局域网内的企业级应用成熟吗？？
Yのo翔メ云 10:36:40
我怎么觉得用着有点死版，好像被个模子套着
Yのo翔メ云 10:37:38
可能还不够深入了解吧
Yのo翔メ云 10:38:02
网上有Flex的成功案例的好像！
Yのo翔メ云 10:38:07
你去搜索ria
Yのo翔メ云 10:38:22
或是 rich internet
奋斗是硬道理 10:38:44
那现在用flex 做局域网内的企业级应用成熟吗？？
看你的实际需求
奋斗是硬道理 10:39:02
且flex2也可以call javascript
Yのo翔メ云 10:39:18
我在想一个问题！如果Flex以后成为主流！哈哈！搜索引擎是不是要更新换代了！
&Artkai 10:39:30
hoho~~
奋斗是硬道理 10:39:43
有可能
我就是没细胞 10:40:01
那赶快 研究搜索引擎 啊
奋斗是硬道理 10:40:07
用flex2做game我感觉不错
  江上浪 10:40:08
flex上adobe提出来的
Yのo翔メ云 10:40:21
不是！应该是去研究FLEX
Yのo翔メ云 10:40:55
现在国内的大站都没有使用FLEX的好像！
Yのo翔メ云 10:41:14
AJAX到是都开使普及了！
奋斗是硬道理 10:42:17
目前flex有几个问题:flex2的应用,搜索引擎搜索不到,大站当然为会考虑了,只会局部应用
Yのo翔メ云 10:42:25
嗯
  江上浪 10:42:47
什么都会抄起来的
  江上浪 10:42:57
就像ajax一样
奋斗是硬道理 10:43:08
且flex2做的应用,.swf比较大,第一次下载会比较慢
奋斗是硬道理 10:43:25
这个也是在www上的一个问题
Yのo翔メ云 10:43:27
嗯！等FLEX再成熟一些肯定会实际应用的
  江上浪 10:44:09
我想这在网上做报表和图表一定可以了
奋斗是硬道理 10:44:13
线上应用是flex2的重点,局域网的应用效果也会不错
奋斗是硬道理 10:44:28
江兄的idea不错
奋斗是硬道理 10:44:54
可惜flex2的charting这一块是要钱的
Yのo翔メ云 10:44:55
做网络相册之类的应用也不错的
  江上浪 10:45:33
好多报表什么的都是结合flash的
  江上浪 10:45:50
看样子flash以后会再度红起来的
Yのo翔メ云 10:45:52
哈哈！不是为了更好的用户体验嘛
Yのo翔メ云 10:46:20
是呀！不再是做做展示动画的时代了！
奋斗是硬道理 10:46:22
flex2的图表确实不错
  江上浪 10:46:27
http://demo.quietlyscheming.com/book/app.html
  江上浪 10:46:34
看看这个页面
╁蓝驿┲→ 10:46:54
都是好人，找个时间疯狂学习下

17 楼 dlee 2007-08-04  

浏览器中Widget组件的发展，有两个方向：
一个方向是基于DHTML技术，充分挖掘DOM+CSS的潜力，开发出各种功能复杂的Widget。
另一个方向是浏览器本身提供一些通用的Widget组件。例如现在Firefox/Opera/Safari浏览器已经能够支持用于绘图的Canvas组件。这三个浏览器的开发商成立了WhatWG组织，提出了一个标准叫做HTML5：
http://www.whatwg.org/specs/web-apps/current-work/
这是该组织自己的标准，并没有得到W3C的认可。

WhatWG组织想要为XHTML1/HTML4添加一些新的组件，将浏览器发展为一个非常强大的应用开发环境。但是W3C看来并不希望将XHTML搞的太复杂，他们希望保持XHTML的简洁性。W3C认可的发展方向是与XHTML1不兼容的XHTML2。

请看：
HTML 的未来，第 1 部分: WHATWG
http://www-128.ibm.com/developerworks/cn/xml/x-futhtml1/
HTML 的未来，第 2 部分: XHTML 2.0
http://www.ibm.com/developerworks/cn/xml/x-futhtml2.html

在这个发展过程中，M$的态度很暧昧。不过可以肯定的是，他们并不希望浏览器本身（不借助某些私有的插件）发展为一个非常强大的应用开发环境。那样的话，大多数的应用都可以基于浏览器来开发了，谁还会在意Windows？

为什么要说上面这些，是因为这些背景信息会极大地影响基于HTML的技术（Ajax/DHTML）未来的发展。HTML诞生就是用来传达信息的，将太多复杂的交互需求塞到HTML中，是否合适？对于信息提供类的网站，基于HTML的技术非常适合。但是对于有非常复杂的交互需求的网站，使用基于HTML的技术来开发，难度太高，甚至有些功能完全无法实现。

我举个例子，例如我们想做一个照片打印的网站，允许用户在上传的照片上面涂鸦，使用各种字体来写字。这样的交互需求，DHTML完全无法做到，只能借助于Flash等RIA技术。

当然，现在绝大多数的网站都是信息提供类的网站，基于HTML的技术已经足够了，我基本上同意DHH和robbin的观点。我一向认为，其他RIA技术与基于HTML的技术所面向的应用领域并不是重合的，完全不可能取代基于HTML的技术。不过在一些特定的领域，其他RIA技术可以成为基于HTML的技术的很好的补充。目前来看，Flash就是基于HTML的技术的最佳的补充。

16 楼 fkpwolf 2007-08-03  

html强的地方在于两字：标准

15 楼 treenode 2007-08-03  

robbin 写道

所以问题就在于Flash和网页的大量交互，但很遗憾的是Flash操纵网页DOM的能力很弱，与传统的JavaScript无法相提并论！所以你会遇到各种意想不到的问题，而这些问题原本用JavaScript却是很简单的事情，例如驱动网页导航，刷新，打开关闭窗口，DIV隐藏显示等等，开发成本就是这么不知不觉升上来的。最终你会发现Flash的开发成本太高！

这个批评很没道理，Flash为什么要操纵网页DOM？DOM结构如何属于网页的实现细节，是不应该暴露给Flash的，这样做等于Flash和页面成了紧耦合的关系，一个很现实的问题：离开网页的话，Flash是不是就没法单独测试了？

合理的做法，应当是Flash通过ExternalInterface回叫Javascript，由JS来操作DOM，Flash只负责发出事件回调，不依赖于HTML的组织结构。插件负责的是页面中一块相对独立的功能，和页面应该只有简明的接口，而不该依赖于彼此的内部实现。如果网页和Flash存在大量交互，说明设计上很可能就有问题。

14 楼 julyboxer 2007-08-03  

robbin 写道

只要web应该是基于文本形式这一点不改变，那么HTML/JS的地位就不会改变，那么AJAX无论如果都是web开发之首选技术。

确实如此.在当前的网络速度限制下..大部分的web都是基于文本这一形式..除非有一天网速提高了..才有可能转向其他形式..但这里面又涉及到用户习惯改变的问题..深入下去是有很多问题存在...到时候并不是采用哪种技术的问题了

13 楼 lordhong 2007-08-03  

mistapostle 写道

我要push信息到前端怎么办

任何支持JMS的messaging server都可以.  Flex支持JMS及其它messaging的方式.

12 楼 lordhong 2007-08-03  

Flex可以直接操作JavaScript, 反过来JavaScript也可以直接操作Flex, 通过一个简单的External接口就可以了.  Flex也可以直接操作HTML DOM.
见过一个应用, Flex里面直接和Google Map/Google Earth交互使用, 酷毙了!

11 楼 sp42 2007-08-03  

weiqingfei 写道

sp42 写道

Javascript的再激活，除了在客户端上参与和(x)html的复兴外，亦正在驾临服务端的开发。参见一则消息：

引用

为了提升google的开发效率，Steve努力尝试说服公司采纳Rails（包括Ruyb）作为开发工具，但是google不予采纳(google不想再增加支持的语言的数量)。Steve决定把Rails移植到JavaScript上去。这意味着一个google有可能在未来开源一个新的项目Rhino on Rails。

限制语言的数量将使得开发人员对代码的贡献度更大，他们无需担心成为不熟悉的语法的牺牲。

每一个公司正式支持的语言都是有成本的：基础架构的支持，文档，培训，代码冗余还有其它因素。虽然编程语言的核心语法都是大同小异，但是剩下的各自独特的语法就难以辨认，尤其是没有明确标准的动态语言，例如Perl,Ptthon,Ruby。Google非常谨慎的保持使用语言的数量。这样就可以构建大量对所用语言非常熟悉的专家。goole目前只使用C++,Java,Python,javascript作为正式的产品开发语言。

详细：http://www.infoq.com/cn/news/2007/06/yegge-rhino-on-rails

早就有了javascript在服务器端的应用了，
helma
http://dev.helma.org/
sun's Phobos
https://phobos.dev.java.net/

最早应该是Netsacpe自己Server端产品的应用吧，还有一些另外js的应用领域，好像SONY的也有
Phobos Intro:
http://weblogs.java.net/blog/robc/archive/2006/05/introducing_pro.html
However，Phobos has been down.
and about helma：
RhinoServlet http://helma.org/pipermail/helma-dev/2006-June/002844.html
Rhino in Spring:
http://rhinoinspring.sourceforge.net/

最近比较新的方案：
Server-Side JavaScript with Rhino, Jetty and MySQL
[url]http://peter.michaux.ca/ [/url]

10 楼 weiqingfei 2007-08-03  

sp42 写道

Javascript的再激活，除了在客户端上参与和(x)html的复兴外，亦正在驾临服务端的开发。参见一则消息：

引用

为了提升google的开发效率，Steve努力尝试说服公司采纳Rails（包括Ruyb）作为开发工具，但是google不予采纳(google不想再增加支持的语言的数量)。Steve决定把Rails移植到JavaScript上去。这意味着一个google有可能在未来开源一个新的项目Rhino on Rails。

限制语言的数量将使得开发人员对代码的贡献度更大，他们无需担心成为不熟悉的语法的牺牲。

每一个公司正式支持的语言都是有成本的：基础架构的支持，文档，培训，代码冗余还有其它因素。虽然编程语言的核心语法都是大同小异，但是剩下的各自独特的语法就难以辨认，尤其是没有明确标准的动态语言，例如Perl,Ptthon,Ruby。Google非常谨慎的保持使用语言的数量。这样就可以构建大量对所用语言非常熟悉的专家。goole目前只使用C++,Java,Python,javascript作为正式的产品开发语言。

详细：http://www.infoq.com/cn/news/2007/06/yegge-rhino-on-rails

早就有了javascript在服务器端的应用了，
helma
http://dev.helma.org/
sun's Phobos
https://phobos.dev.java.net/

9 楼 neuhawk 2007-08-03  

silverlight 1.0/ 1.1操作dom没问题的,
c#和js操作都可以.