锁定老帖子 主题:AJAX与RIA技术之我见
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2007-07-31
我就喜欢HTML/CSS/JavaScript,那又怎么样!》,大意是说,目前热炒的RIA技术并不能够取代AJAX技术,而事实上我们还没有发挥出HTML的全部潜力,我本人很享受HTML/CSS/JS给给我的开发体验云云。
DHH于6月底曾经发表过一篇文章,名为《我比较赞成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开发之首选技术。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-08-02
见过一些全flash的web 应用 叹为观止
|
|
返回顶楼 | |
发表时间:2007-08-02
为什么就不可以整个页面完全使用flash或者SilverLight呢?
|
|
返回顶楼 | |
发表时间:2007-08-02
个人更喜欢开发 Ajax App,不过 YAHOO 的 flash 地图应用也不错哦~
|
|
返回顶楼 | |
发表时间:2007-08-02
weiqingfei 写道 为什么就不可以整个页面完全使用flash或者SilverLight呢?
完全可以,但似乎走向了一个极端,为何要抛弃 HTML 呢? |
|
返回顶楼 | |
发表时间:2007-08-02
所以, 如果要做一个系统框架, 比如Netvibes这样的, 必须用HTML, 因为要整合各种widget. 而对于某个应用, 如果界面要求比较高,又不计成本,那可以用Flash/Flex
其实Flex/OpenLaszlo也不见得门槛有多低, 不见得熟悉JavaScript就能很快上手 |
|
返回顶楼 | |
发表时间:2007-08-02
我要push信息到前端怎么办
|
|
返回顶楼 | |
发表时间:2007-08-03
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 |
|
返回顶楼 | |
发表时间:2007-08-03
用flash对dom进行控制是有点困难
但还有其它的问题, 比如每页flash的开发,维护成本高于 js才是关键。 还有网速的考虑。 |
|
返回顶楼 | |
发表时间:2007-08-03
silverlight 1.0/ 1.1操作dom没问题的,
c#和js操作都可以. |
|
返回顶楼 | |