AJAX，一个注定昙花一现的技术

key

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端。

key

这两天想弄一个在线视频播放器。目标是在LAN范围内浏览自己的视频，并在手机上在线观看。

这个不难弄，因为Android能支持mp4的在线观看（它不支持rstp这种流模式，恶心的Google）。
由于Android对于视频格式要求有很多限制，我就不得不做一个在线转换程序。
我原来的设想是做一个on-the-fly的转换器，在利用服务器端的运算能力，实时对视频进行转换。
但后来发现以我目前所掌握的有限的视频知识，做这个on-the-fly的转换器并不是件容易的事。
所以退而求其次，我做一个简单的web程序，通过点击而启动转换器，生成新的新的视频文件，
再播放。

整套东西都不复杂。无聊中，我就想用Ajax来实现。于是想试一下传说中的jQuery，后来放弃了；
再试试传说中的GWT。这东西很Cool，最Cool的是Google让Ajax的开发变成一种艺术。然而艺术这东西
是用来欣赏的，和一个艺术家上床很容易发恶梦。我最后发现GWT是一个恶梦。于是我又回到我的JSP/Servlet
世界。

你一定觉得我很懒，没耐心，学习能力也差。的确，我有以上三个特点，而所有的程序员都是以上三个特点。
这就是为什么我会觉得Ajax最后会被放弃的原因。

周星星1832

说ajax昙一现，有点过了，至少在目前是趋势。

ajax和web services 没有可比性啊，一个server side,一个client side.
确切的来说，两者还相辅相成，ajax不能直接cross domian，用web service来cross domian是个不错的选择

mayabin

呵呵，Key的感慨很大啊。
Ajax刚开始的概念很狭窄，就像你说的那样，javascript很让人烦的，我也不喜欢。
但是现在的ajax，代表的是一种概念，毕竟以前的传统的WEB开发确实没有异步传输，良好的交互。
现在Web开发的新概念， RIA， 其实包含了Ajax在里面，大家也都希望能把这些优点保留下来。像微软的Silverlight， Adobe的Flex，，Sun的JavaFX...

楼上说的Ajax和Web Service没有可比性， 我同意， 根本不是一个层面上的东西。但是也不能说Ajax是Client Side的技术，因为现在Ajax的概念扩大了，也有Sever side来实现Ajax的。

yuba

我认为Ajax也好，Agile，Ruby之类的也罢，都是一个回答，对某一类问题的回答

但问题是，当他们开始流行以后，大多数人都不会在意，原来的问题是什么

不考虑眼下的实际情况，言必称Ajax，Agile，etc，好像他们是银弹

我相信，越来越多人的在真正的使用这些技术流程方法之后，会发现和楼主一样的结论

“某个技术（流程或方法）不适合某种需求”

所以，让更多数的人明白这个道理的方法就是

让“叶公”真正的见到“龙”

多一些技术流程方法的使用者，少一些技术流程方法的布道者

ritz

are you joking?
你是说gmail是昙花一现么？

uniwg

打算MOVE到悉尼了，暂时住city的ultimo，希望以后悉尼的同志们聚会BBQ。

key

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 发表

                               
登录/注册后可看大图

are you joking?
你是说gmail是昙花一现么？

key

住市区呀。。。不错啵

原帖由 uniwg 于 29-11-2009 11:35 发表

                               
登录/注册后可看大图

打算MOVE到悉尼了，暂时住city的ultimo，希望以后悉尼的同志们聚会BBQ。

someonehappy

最近也玩了下GWT，没有做楼主那样的比较特别的应用，光从做一些常见的业务网站来说，已经很不错了，也谈不上噩梦吧。
至于CS，我觉得最大的问题就在于前端。对于做一个客户很分散的系统，对客户端没几乎没有什么要求，很长一段时间内也不需要考虑什么升级问题，这是一个很大的便利。某种角度上来讲有点“编译一次到处执行”的味道。除非你的系统对本地资源的使用要求非常高。具体还是要具体项目的需求。
在手机上的应用也许稍微特别一些。

zeng_ap

个人感觉，以Adobe公司的基于Flash技术的RIA将会是主流，98%以上的占有率，100%的兼容性，功能强大的多媒体展示技术（语音、视频...）、与各种服务器语言的交互性(XML，AMF PHP/JSP...)、统一的界面展现，... 而且，Adobe的AIR产品基本上算是个C/S开发工具

key

Flash的确很牛X，可惜Adobe不是一个很强悍的公司。

原帖由 zeng_ap 于 29-11-2009 18:49 发表

                               
登录/注册后可看大图

个人感觉，以Adobe公司的基于Flash技术的RIA将会是主流，98%以上的占有率，100%的兼容性，功能强大的多媒体展示技术（语音、视频...）、与各种服务器语言的交互性(XML，AMF PHP/JSP...)、统一的界面展现，... 而且， ...

yuba

原帖由 key 于 29-11-2009 19:06 发表

                               
登录/注册后可看大图

可惜Adobe不是一个很强悍的公司。

穷兵黩武自古没有几个有好下场

看看adobe首页的产品，就知道这家公司的后劲

如果出了仅支持Air的上网本，销量未必比Chrome OS低

coredump

技术，就像水里面的颗粒，被时代的棍子一搅，各种技术都会出现，混在IT的这碗汤里。等时间使它们安静下来，会只剩下很简单层次。而作为最动态的Javascript相关的一系列技术，将会是这碗汤的上层泡沫而得以保留。低下的是那些历久弥坚的东西C/C++, Java ...，而且最底下和最上层的直接联系将会越来越和谐，而中间会逐步变的很清澈，等待下一次水被搅浑。

yuba

下层的会历久弥坚

上层的会举而不坚，或坚而不久

界面的变化远比后台或底层的大很多，且没有adapter可以封装适应新的潮流

sliuhao

原帖由 yuba 于 29-11-2009 09:41 发表

                               
登录/注册后可看大图

我认为Ajax也好，Agile，Ruby之类的也罢，都是一个回答，对某一类问题的回答

但问题是，当他们开始流行以后，大多数人都不会在意，原来的问题是什么

不考虑眼下的实际情况，言必称Ajax，Agile，etc，好像他们是 ...

多一些技术流程方法的使用者，少一些技术流程方法的布道者

问题是这个市场乃至世界现在都不care这些，需求是被制造出来的.
技术流程方法的使用者只能是不幸的围观者而已...

yuba

梨子吃了才知道合不合需求，但是有些布道者是不考虑不同人有不同需求的

如果吃的人少，或者不合口味但是没有话语权，业界充斥的就是xxx是银弹

所以多一些楼主这样去吃，吃得不爽就分享为什么吃得不爽的，供其他围观者参考

围观不幸，扛着经理指定的银弹上战场就更不幸了

key

老实说，因为我不是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 发表

                               
登录/注册后可看大图

梨子吃了才知道合不合需求，但是有些布道者是不考虑不同人有不同需求的

如果吃的人少，或者不合口味但是没有话语权，业界充斥的就是xxx是银弹

所以多一些楼主这样去吃，吃得不爽就分享为什么吃得不爽的，供其他 ...

刘叔

谢谢楼主的分析！

我今天才发现，其实Apache是一个短视的组织、一个注定昙花一现的组织......

它好多项目中都专门为AJAX开发接口、提供支持，有几个还和AJAX结合得相当紧密。惨～～～

借楼主宝地，发图纪念一下曾经的辉煌。

                               
登录/注册后可看大图

key

讽刺是没有意义的，或者你会觉得这是一种幽默。

Ajax对于不同的人有不同的意义。我这个文章，更多是提醒现在还努力编写低层的JS代码来实现Ajax的开发同学，
因为可能是一个很危险的行为。如果最后Ajax的实现被更高层的实现来代替，或者根本上被新的C/S结构代码，
那我们的饭碗就有点玄了。你不觉得这样的讨论有点意义吗？

至于Apache上的东西，你要知道多少大公司在背后推动。他们是一种竞争。而且Ajax的技术架构处于极不稳定的时期，
如果他们能在Ajax架构上有重大的影响，对于他们的产品线会有很重要的作用。比如Google，如果使用GWT的人越来越多，
流行程度达到了现在Java、Python这样的水平，他们的Chrome再对这些Ajax boilerplate进行优化，
在速度上还有人能和他们相比？所以鹿死谁手，这个“鹿”是死定了，只是谁经的手而已（参考《鹿鼎记》）。

原帖由 刘叔 于 2-12-2009 00:07 发表

                               
登录/注册后可看大图

谢谢楼主的分析！

我今天才发现，其实Apache是一个短视的组织、一个注定昙花一现的组织......

它好多项目中都专门为AJAX开发接口、提供支持，有几个还和AJAX结合得相当紧密。惨～～～

借楼主宝地，发图纪念 ...

周星星1832

原帖由 key 于 1-12-2009 23:48 发表

                               
登录/注册后可看大图

老实说，因为我不是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?
本身就不是一类的东西。

sliuhao

原帖由 yuba 于 1-12-2009 21:32 发表

                               
登录/注册后可看大图

梨子吃了才知道合不合需求，但是有些布道者是不考虑不同人有不同需求的

如果吃的人少，或者不合口味但是没有话语权，业界充斥的就是xxx是银弹

所以多一些楼主这样去吃，吃得不爽就分享为什么吃得不爽的，供其他 ...

围观不幸，扛着经理乃至整个公司指定的银弹上战场就更不幸了 - 这不是一个事实么？ 赫赫...
就合SOA一样， 2004年我说那个东西没那么玄乎， 这个可是众怒哦， 很多人不是靠所谓的银弹鸡犬升天么？
"银弹"只是一个政治工具而已，大多数布道者其实只是一个政客而已...

yuba

看来你更喜欢葡萄而不是梨子

sliuhao

很多人不是号称喜欢葡萄， 其实是爱梨子么？

yuba

抽象来说，一切都是昙花一现

但是每一个昙花都能让一部分人先“富”起来

我们这些围观了无数昙花凋零还没有升天的人

最好闭门面壁，而不是感慨昙花，粪土政客

呵呵

key

你说的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 发表

                               
登录/注册后可看大图

jquery 就是js.
还有其他流行的yui等封装ajax的framwork都是js.
js确实不难搞，难的是调试。而且js也确实不会像java那么多代码。
如果js,ajax消亡，也就是说基于js的所有js framework都会消亡，可能吗？
连goo ...

mayabin

使用JS的Ajax已经在失势了。没啥可讨论的。
大家往前看 ，看看JSF，还有RIA吧。

sliuhao

原帖由 yuba 于 2-12-2009 10:51 发表

                               
登录/注册后可看大图

抽象来说，一切都是昙花一现

但是每一个昙花都能让一部分人先“富”起来

我们这些围观了无数昙花凋零还没有升天的人

最好闭门面壁，而不是感慨昙花，粪土政客

呵呵

这不就是你我这些人的真实写照么？
什么PMP,CMM,SAP,SOA,EJB,AJAX,DW,DM， SSIS....都是过眼云烟，该干什么还是干什么...
你我的价值就是所有人都解决不了的问题， 你我能解决， 在这些问题面前， 给我谈银弹的的都闭嘴。
还好，上战场可以自带武器....,不然死不瞑目啊！......

yuba

原帖由 mayabin 于 2-12-2009 10:53 发表

                               
登录/注册后可看大图

大家往前看 ，看看JSF，还有RIA吧。

帮助另一些政客升天的，供其他人围观的另一个昙花




我有一种找到真理的快感

key

能提供点“失势”证据？比如链接之类？

原帖由 mayabin 于 2-12-2009 10:53 发表

                               
登录/注册后可看大图

使用JS的Ajax已经在失势了。没啥可讨论的。
大家往前看 ，看看JSF，还有RIA吧。