AJAX，一个注定昙花一现的技术
Ajax，随着web 2.0时代而流行起来的技术，现在还广受欢迎，并正迅猛发展。我不是一个web开发人员，贸然批评这样一个web核心技术应该很不适当。
Ajax的基础是javascript，一种脚本语言，无变量定义（严格的定义）、
无强类型check、只有有限的面向对象支持。更重要的是，javascript是一种
“死掉”的语言，无人去推进、推广javascript的新标准；
而它的依赖平台，web browser则各有各的发展，各有各的变化。
与之相对的是标准化的Web Services技术。当然，这两者不能说是冲突；与Ajax冲突
的不是web services，而是因应web services而可能滚土重来的C/S技术。
这种C/S技术的C端有可能是老式的Windows平台、X-Windows平台的GUI程序，
也有可能是手机上的小应用，也有可能是浏览器上的插件。以前我们对C/S避而远之，
是因为几个原因，其中通信协议过于自由、C端过重而无法跨平台、界面过于专有
导致用户必须面对不同的界面元素而重新学习使用。但再看现在的Web应用，尤其是
Ajax流行后的Web，问题一和问题三都存在，而Ajax和C/S相比，存在严重的劣势：
开发难度大，维护成本高，运行效率低，浏览器的多样性带来的跨浏览器问题等。
反观C/S，以手机应用来看，由于界面的截然不同，强行要求手机应用与PC应用的界面
一致是没有意义的；手机界面本就简单，所以基本上不存在因为界面不同而增加的用户
学习成本（我说的是增加部分）。
Google把它业务做成了基于浏览器的形式进行发布，这是一种发布策略。但在Android上，
Google又重新把它的业务做成了C/S实现，因为只有C/S结构的程序跑在手机上才让能
更好地发挥手机有限的资源。Google Chrome，无论是Chrome Browser还是Chrome OS，
我个人的看法，它要的不是一个浏览器，而是一个插件平台。这样一个插件平台，最终就让
开发者归附于它的浏览器，而不是OS本身。这和Java提出的跨平台性是同一道理，
只是Chrome要做的是让程序员在浏览器上实现C端。
感想来源
这两天想弄一个在线视频播放器。目标是在LAN范围内浏览自己的视频，并在手机上在线观看。这个不难弄，因为Android能支持mp4的在线观看（它不支持rstp这种流模式，恶心的Google）。
由于Android对于视频格式要求有很多限制，我就不得不做一个在线转换程序。
我原来的设想是做一个on-the-fly的转换器，在利用服务器端的运算能力，实时对视频进行转换。
但后来发现以我目前所掌握的有限的视频知识，做这个on-the-fly的转换器并不是件容易的事。
所以退而求其次，我做一个简单的web程序，通过点击而启动转换器，生成新的新的视频文件，
再播放。
整套东西都不复杂。无聊中，我就想用Ajax来实现。于是想试一下传说中的jQuery，后来放弃了；
再试试传说中的GWT。这东西很Cool，最Cool的是Google让Ajax的开发变成一种艺术。然而艺术这东西
是用来欣赏的，和一个艺术家上床很容易发恶梦。我最后发现GWT是一个恶梦。于是我又回到我的JSP/Servlet
世界。
你一定觉得我很懒，没耐心，学习能力也差。的确，我有以上三个特点，而所有的程序员都是以上三个特点。
这就是为什么我会觉得Ajax最后会被放弃的原因。 说ajax昙一现，有点过了，至少在目前是趋势。
ajax和web services 没有可比性啊，一个server side,一个client side.
确切的来说，两者还相辅相成，ajax不能直接cross domian，用web service来cross domian是个不错的选择 呵呵，Key的感慨很大啊。
Ajax刚开始的概念很狭窄，就像你说的那样，javascript很让人烦的，我也不喜欢。
但是现在的ajax，代表的是一种概念，毕竟以前的传统的WEB开发确实没有异步传输，良好的交互。
现在Web开发的新概念， RIA， 其实包含了Ajax在里面，大家也都希望能把这些优点保留下来。像微软的Silverlight， Adobe的Flex，，Sun的JavaFX...
楼上说的Ajax和Web Service没有可比性， 我同意， 根本不是一个层面上的东西。但是也不能说Ajax是Client Side的技术，因为现在Ajax的概念扩大了，也有Sever side来实现Ajax的。
一个很有意思的讨论
我认为Ajax也好，Agile，Ruby之类的也罢，都是一个回答，对某一类问题的回答但问题是，当他们开始流行以后，大多数人都不会在意，原来的问题是什么
不考虑眼下的实际情况，言必称Ajax，Agile，etc，好像他们是银弹
我相信，越来越多人的在真正的使用这些技术流程方法之后，会发现和楼主一样的结论
“某个技术（流程或方法）不适合某种需求”
所以，让更多数的人明白这个道理的方法就是
让“叶公”真正的见到“龙”
多一些技术流程方法的使用者，少一些技术流程方法的布道者 are you joking?
你是说gmail是昙花一现么？;P 打算MOVE到悉尼了，暂时住city的ultimo，希望以后悉尼的同志们聚会BBQ。:) gmail是一项service，Ajax是一个技术。Ajax是一种无奈的技术，个人认为Google一方面在善用这个技术，
另一方面，在放弃这个技术。当然，这只是个人观点。
Android的出现，说明了Google已经不想依赖Browser把业务推送到手机上。你看Google Services在iPhone中的实现
是多么蹩脚吧。
Chrome浏览器的出现，说明了Google需要打造一个专用的、高于OS的一个平台。如果只需要Web就可以实现他的业务，
他可以依赖Firefox之类的东西来达到目的。
Chrome OS自称是浏览器的一个延伸版，而不是一个OS。开发模式主要是web应用，以及chrome插件来完成。
Ajax还有一段很长的路可以走，然而，Ajax很快就不再是我们原来认识的Ajax，我怀疑接下来浏览器会打造
能优化Ajax执行的东西。这东西并不是单纯意义的JS加速，而是大段大段的boilerplate的加速。这样就必然导致新的
JS语言标准的产生。
Ajax的最重要的特点，是能够依赖现有的浏览器技术和网页设计标准，做出以前没有做出的效果。
这是一种妥协实现，生命线不会太长。
原帖由 ritz 于 29-11-2009 11:10 发表 http://www.freeoz.org/bbs/images/common/back.gif
are you joking?
你是说gmail是昙花一现么？;P 住市区呀。。。不错啵
原帖由 uniwg 于 29-11-2009 11:35 发表 http://www.freeoz.org/bbs/images/common/back.gif
打算MOVE到悉尼了，暂时住city的ultimo，希望以后悉尼的同志们聚会BBQ。:) 最近也玩了下GWT，没有做楼主那样的比较特别的应用，光从做一些常见的业务网站来说，已经很不错了，也谈不上噩梦吧。
至于CS，我觉得最大的问题就在于前端。对于做一个客户很分散的系统，对客户端没几乎没有什么要求，很长一段时间内也不需要考虑什么升级问题，这是一个很大的便利。某种角度上来讲有点“编译一次到处执行”的味道。除非你的系统对本地资源的使用要求非常高。具体还是要具体项目的需求。
在手机上的应用也许稍微特别一些。 个人感觉，以Adobe公司的基于Flash技术的RIA将会是主流，98%以上的占有率，100%的兼容性，功能强大的多媒体展示技术（语音、视频...）、与各种服务器语言的交互性(XML，AMF PHP/JSP...)、统一的界面展现，... 而且，Adobe的AIR产品基本上算是个C/S开发工具 Flash的确很牛X，可惜Adobe不是一个很强悍的公司。
原帖由 zeng_ap 于 29-11-2009 18:49 发表 http://www.freeoz.org/bbs/images/common/back.gif
个人感觉，以Adobe公司的基于Flash技术的RIA将会是主流，98%以上的占有率，100%的兼容性，功能强大的多媒体展示技术（语音、视频...）、与各种服务器语言的交互性(XML，AMF PHP/JSP...)、统一的界面展现，... 而且， ... 原帖由 key 于 29-11-2009 19:06 发表 http://www.freeoz.org/bbs/images/common/back.gif
可惜Adobe不是一个很强悍的公司。
穷兵黩武自古没有几个有好下场
看看adobe首页的产品，就知道这家公司的后劲
如果出了仅支持Air的上网本，销量未必比Chrome OS低 技术，就像水里面的颗粒，被时代的棍子一搅，各种技术都会出现，混在IT的这碗汤里。等时间使它们安静下来，会只剩下很简单层次。而作为最动态的Javascript相关的一系列技术，将会是这碗汤的上层泡沫而得以保留。低下的是那些历久弥坚的东西C/C++, Java ...，而且最底下和最上层的直接联系将会越来越和谐，而中间会逐步变的很清澈，等待下一次水被搅浑。
回复 #14 coredump 的帖子
下层的会历久弥坚上层的会举而不坚，或坚而不久
界面的变化远比后台或底层的大很多，且没有adapter可以封装适应新的潮流 原帖由 yuba 于 29-11-2009 09:41 发表 http://www.freeoz.org/bbs/images/common/back.gif
我认为Ajax也好，Agile，Ruby之类的也罢，都是一个回答，对某一类问题的回答
但问题是，当他们开始流行以后，大多数人都不会在意，原来的问题是什么
不考虑眼下的实际情况，言必称Ajax，Agile，etc，好像他们是 ...
多一些技术流程方法的使用者，少一些技术流程方法的布道者
问题是这个市场乃至世界现在都不care这些，需求是被制造出来的.
技术流程方法的使用者只能是不幸的围观者而已...
回复 #16 sliuhao 的帖子
梨子吃了才知道合不合需求，但是有些布道者是不考虑不同人有不同需求的如果吃的人少，或者不合口味但是没有话语权，业界充斥的就是xxx是银弹
所以多一些楼主这样去吃，吃得不爽就分享为什么吃得不爽的，供其他围观者参考
围观不幸，扛着经理指定的银弹上战场就更不幸了 老实说，因为我不是web开发人员，这样评价Ajax的确有失公平。在我眼中，Ajax和汇编差不多，Ajax的思想会被保留，而且一定要保留，
但Ajax的技术本身会变化、淡化、最后大家可能把Ajax也忘了。
目前Ajax的流行，在于Ajax之外没有别的选择。就象高级语言出现之前汇编也横行。问题是，那时大家都没有高级语言的思想。而现在，
大家都知道什么设计模式、系统架构。做Ajax应用，Google即使称不上全世界最好，也至少是最好之一。Google Mail已经让人叹为观止，
但再看Google Wave，你会吃惊Web开发竟然能达到这种高度。但问题是，Google GWT真的是Ajax？我对GWT了解不多，以我有限的了解，
GWT是一个“构建”->“编码"->"编译"->"运行"的过程，全程没有Javascript的参与，开发者开发的是一套C/S结构的Java系统，
然后通过Google的"Ajax Compiler"生成一套真正的Ajax实现。各位同学想想，这是什么？10多年前的Turbo C/Turbo Parscal不就是
这个样子吗？你觉得你是在写C还是写汇编呢？
我对Ajax的另一个认识是DWR。我是05-06年左右用过这个东西，和现在相比当然区别很大了；而我对DWR的印象也基本上没有多少，只知道
自己用过这东西。刚才看了一下DWR的Tutorial，它的确是很接近Ajax最初的定义：
HTML + JAVASCRIPT + 后台
DWR把在后台和Javascript之间建立了一条桥梁，通过自身带的util，把POJO转换成XML的响应（我同事还天天给我“讲解”全世界都喜欢XML
是因为XML有结构、有表达能力等，所以应该直接用XML；他也不想想我天天看这类代码，都是极力避免直接操作XML，唉。。。无语）。DWR要求
开发人员只需要知道最简单的Javascript和POJO就能利用Ajax进行程序开发。然而DWR对Ajax是一种很低层的支持，一方面让程序员直观地使用
Ajax的设计原义，另一方面则无法象GWT那样变幻出无数让人吃惊的效果。
我最后一个对Ajax的认识是自己写实现代码，一行行的Javascript到一行行的Java，我连XML都是通过Java/Servlet/Spring这样的结构返回的。
然而，以一个小应用来说，我会编向DWR和直接的写Ajax实现；但如果我写大应用，比如有大量的drag & drop，我会选择GWT。GWT可以说是另一种
开发语言，只是以Java/XML作为表达的形式。我必须以“学习一种新语言”的态度来对待GWT。这就是我所说的恶梦。如果你有时间，有精力，也有需求，
那恶梦很容易变成美梦。
还有一个很著名的Ajax实现框架：jQuery，我一直没有机会试。jQuery是以JS为基本的吧？
以我的认识，系统必须会一步步的走向更完整，更复杂。GWT这类的“编译”型Ajax框架会是大势所趋（认识jQuery的同学请出来批评一下）。
如果你认同我这个观点，那就知道我为什么说Ajax会很快消亡 —— 大家眼中不再是一个基于JS的Ajax技术，而是一种
基于某个精心设计的编译平台的Web实现。我们会忘掉Javascript。
但进一步说，如果大家都依赖了这种编译平台式的Ajax，那接下来，这些制作编译平台的同学都会利用自己的平台优势，逐步推出
平台相关的优化。比如GWT产生的优化JS代码就不是人能读取的了。再接下来，就是我前面说的boilerplate级的优化。
说到底，就是JS太难搞了。有人会说JS不难搞。OK，我写10kJava代码虽然不轻松，但不会很头痛。你写 10 K JS代码我看看？
如果你一定要说，会有谁写 10 K JS，JS都是小小的几段就行了。。。。那我无语了。
原帖由 yuba 于 1-12-2009 21:32 发表 http://www.freeoz.org/bbs/images/common/back.gif
梨子吃了才知道合不合需求，但是有些布道者是不考虑不同人有不同需求的
如果吃的人少，或者不合口味但是没有话语权，业界充斥的就是xxx是银弹
所以多一些楼主这样去吃，吃得不爽就分享为什么吃得不爽的，供其他 ... 谢谢楼主的分析！
我今天才发现，其实Apache是一个短视的组织、一个注定昙花一现的组织......
它好多项目中都专门为AJAX开发接口、提供支持，有几个还和AJAX结合得相当紧密。惨～～～
借楼主宝地，发图纪念一下曾经的辉煌。
http://myfaces.apache.org/sandbox/img/banners/apache_banner.png 讽刺是没有意义的，或者你会觉得这是一种幽默。
Ajax对于不同的人有不同的意义。我这个文章，更多是提醒现在还努力编写低层的JS代码来实现Ajax的开发同学，
因为可能是一个很危险的行为。如果最后Ajax的实现被更高层的实现来代替，或者根本上被新的C/S结构代码，
那我们的饭碗就有点玄了。你不觉得这样的讨论有点意义吗？
至于Apache上的东西，你要知道多少大公司在背后推动。他们是一种竞争。而且Ajax的技术架构处于极不稳定的时期，
如果他们能在Ajax架构上有重大的影响，对于他们的产品线会有很重要的作用。比如Google，如果使用GWT的人越来越多，
流行程度达到了现在Java、Python这样的水平，他们的Chrome再对这些Ajax boilerplate进行优化，
在速度上还有人能和他们相比？所以鹿死谁手，这个“鹿”是死定了，只是谁经的手而已（参考《鹿鼎记》）。
原帖由 刘叔 于 2-12-2009 00:07 发表 http://www.freeoz.org/bbs/images/common/back.gif
谢谢楼主的分析！
我今天才发现，其实Apache是一个短视的组织、一个注定昙花一现的组织......
它好多项目中都专门为AJAX开发接口、提供支持，有几个还和AJAX结合得相当紧密。惨～～～
借楼主宝地，发图纪念 ... 原帖由 key 于 1-12-2009 23:48 发表 http://www.freeoz.org/bbs/images/common/back.gif
老实说，因为我不是web开发人员，这样评价Ajax的确有失公平。在我眼中，Ajax和汇编差不多，Ajax的思想会被保留，而且一定要保留，
但Ajax的技术本身会变化、淡化、最后大家可能把Ajax也忘了。
目前Ajax的流行，在 ...
jquery 就是js.
还有其他流行的yui等封装ajax的framwork都是js.
js确实不难搞，难的是调试。而且js也确实不会像java那么多代码。
如果js,ajax消亡，也就是说基于js的所有js framework都会消亡，可能吗？
连google都有自己基于js 的js framework.
假设没了js，那web就变得无比枯燥了。
js消亡了，那action script也基本消亡了。
靠web service?
本身就不是一类的东西。 原帖由 yuba 于 1-12-2009 21:32 发表 http://www.freeoz.org/bbs/images/common/back.gif
梨子吃了才知道合不合需求，但是有些布道者是不考虑不同人有不同需求的
如果吃的人少，或者不合口味但是没有话语权，业界充斥的就是xxx是银弹
所以多一些楼主这样去吃，吃得不爽就分享为什么吃得不爽的，供其他 ...
围观不幸，扛着经理乃至整个公司指定的银弹上战场就更不幸了 - 这不是一个事实么？ 赫赫...
就合SOA一样， 2004年我说那个东西没那么玄乎， 这个可是众怒哦， 很多人不是靠所谓的银弹鸡犬升天么？
"银弹"只是一个政治工具而已，大多数布道者其实只是一个政客而已...
回复 #22 sliuhao 的帖子
看来你更喜欢葡萄而不是梨子回复 #23 yuba 的帖子
很多人不是号称喜欢葡萄， 其实是爱梨子么？终于碰到明白人了
抽象来说，一切都是昙花一现但是每一个昙花都能让一部分人先“富”起来
我们这些围观了无数昙花凋零还没有升天的人
最好闭门面壁，而不是感慨昙花，粪土政客
呵呵 你说的JS不难，是指JS语法不难吧。
正如你指出的，JS的调试是伤硬，除调试之外，所有的脚本语言都缺少编译时检查，大量的bug要留到运行时动态发现。
JS的另一个问题就是容易被抄袭。如果你的程序只是一些小玩意，那没什么。但如果大量的元素构建在JS上，
而这些元素又是你最重要的心血之作，你就会考虑是否需要保护起来了。可怕的是，JS的目标就是要让用户下载来使用，
传播是它存在的目的。
JS的代码不是不需要象Java一样多，象Google Wave这样的系统下来，是否有人统计过它需要多少JS代码？
我们都知道代码量问题导致了OOP的产生，可见代码量会引来编程模式的重大改变。而AJAX的流行，是必然导致JS代码的庞大，
接下来怎样有效管理这些代码就成了重要问题。
代码量大了之后，执行也就变成一个问题。现在浏览器的性能比较就都是JS执行速度的比较了，比如Chrome的JS引擎还引出
一个JS引擎天才之类的神奇，正正说明JS给浏览器带来的重大运行负担。
我们都知道计算机硬件在一日千里的发展，但也别忘了大量的业务开始向移动个人设备的变迁。这些设备的计算能力就成为开发者
和架构者必须考虑的问题。AJAX是一种好的表现概念，而构建于浏览器的高层应用（相对于构建在OS的低层应用而言）是非操作
系统开发者一个重要战场。然而JS作为一种脚本语言而带来的问题，尤其是JS在标准化方面没有相应跟进的问题，最终是否会引发
一种新的技术架构的出现来代替它，我个人观点偏向于”是“。
至于我提到WEB SERVICES，这是一种考虑点。WEB SERVICES和JS关注的点不同，这在我最前面的文章就提到了。我提出WEB SERVICES
是说由WEB SERVICES带来的C/S结构的重现；浏览器战争又会带来播件开发的重大发展，让C/S中C端的发布不再是让用户主动的安装，
而是通过浏览器主动推进，以解决了以前C端难安装、难发布问题。正如Chrome OS中提到，他们将利用这个浏览器来充分使用硬件的特性，
这种特性当然包括很多种了，其中之一，应该是动态元素的渲染；显然，如果我们的AJAX还是一行接一行的JS，我相信这种动态元素渲染
就难以发展起来。或者你觉得这是GOOGLE的一家之言，我也认为是一家之言，但言之成理，很有可能成为一种发展的方向。
原帖由 lufumin1832 于 2-12-2009 09:49 发表 http://www.freeoz.org/bbs/images/common/back.gif
jquery 就是js.
还有其他流行的yui等封装ajax的framwork都是js.
js确实不难搞，难的是调试。而且js也确实不会像java那么多代码。
如果js,ajax消亡，也就是说基于js的所有js framework都会消亡，可能吗？
连goo ... 使用JS的Ajax已经在失势了。没啥可讨论的。
大家往前看 ，看看JSF，还有RIA吧。 原帖由 yuba 于 2-12-2009 10:51 发表 http://www.freeoz.org/bbs/images/common/back.gif
抽象来说，一切都是昙花一现
但是每一个昙花都能让一部分人先“富”起来
我们这些围观了无数昙花凋零还没有升天的人
最好闭门面壁，而不是感慨昙花，粪土政客
呵呵
这不就是你我这些人的真实写照么？
什么PMP,CMM,SAP,SOA,EJB,AJAX,DW,DM， SSIS....都是过眼云烟，该干什么还是干什么...
你我的价值就是所有人都解决不了的问题， 你我能解决， 在这些问题面前， 给我谈银弹的的都闭嘴。
还好，上战场可以自带武器....,不然死不瞑目啊！...... 原帖由 mayabin 于 2-12-2009 10:53 发表 http://www.freeoz.org/bbs/images/common/back.gif
大家往前看 ，看看JSF，还有RIA吧。
帮助另一些政客升天的，供其他人围观的另一个昙花
我有一种找到真理的快感 能提供点“失势”证据？比如链接之类？
原帖由 mayabin 于 2-12-2009 10:53 发表 http://www.freeoz.org/bbs/images/common/back.gif
使用JS的Ajax已经在失势了。没啥可讨论的。
大家往前看 ，看看JSF，还有RIA吧。
页:
[1]
2