FreeOZ论坛

标题: AJAX，一个注定昙花一现的技术 [打印本页]

作者: key 时间: 29-11-2009 07:39
标题: 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端。

作者: key 时间: 29-11-2009 07:52
标题: 感想来源
这两天想弄一个在线视频播放器。目标是在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 时间: 29-11-2009 08:47
说ajax昙一现，有点过了，至少在目前是趋势。

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

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

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

作者: yuba 时间: 29-11-2009 09:41
标题: 一个很有意思的讨论
我认为Ajax也好，Agile，Ruby之类的也罢，都是一个回答，对某一类问题的回答

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

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

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

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

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

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

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

作者: ritz 时间: 29-11-2009 11:10
are you joking?
你是说gmail是昙花一现么？

作者: uniwg 时间: 29-11-2009 11:35
打算MOVE到悉尼了，暂时住city的ultimo，希望以后悉尼的同志们聚会BBQ。

作者: key 时间: 29-11-2009 11:35
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 时间: 29-11-2009 11:36
住市区呀。。。不错啵

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

 登录/注册后可看大图

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

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

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

作者: key 时间: 29-11-2009 19:06
Flash的确很牛X，可惜Adobe不是一个很强悍的公司。

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

 登录/注册后可看大图

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

作者: yuba 时间: 30-11-2009 10:23

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

 登录/注册后可看大图

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

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

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

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

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

作者: yuba 时间: 30-11-2009 20:18
标题: 回复 #14 coredump 的帖子
下层的会历久弥坚

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

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

作者: sliuhao 时间: 1-12-2009 21:17

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

 登录/注册后可看大图

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

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

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

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

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

作者: yuba 时间: 1-12-2009 21:32
标题: 回复 #16 sliuhao 的帖子
梨子吃了才知道合不合需求，但是有些布道者是不考虑不同人有不同需求的

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

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

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

作者: key 时间: 1-12-2009 23:48
老实说，因为我不是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是银弹

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

作者: 刘叔 时间: 2-12-2009 00:07
谢谢楼主的分析！

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

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

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

作者: key 时间: 2-12-2009 00:19
讽刺是没有意义的，或者你会觉得这是一种幽默。

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 时间: 2-12-2009 09:49

原帖由 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 时间: 2-12-2009 10:39

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

 登录/注册后可看大图

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

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

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

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

作者: yuba 时间: 2-12-2009 10:45
标题: 回复 #22 sliuhao 的帖子
看来你更喜欢葡萄而不是梨子

作者: sliuhao 时间: 2-12-2009 10:50
标题: 回复 #23 yuba 的帖子
很多人不是号称喜欢葡萄，其实是爱梨子么？

作者: yuba 时间: 2-12-2009 10:51
标题: 终于碰到明白人了
抽象来说，一切都是昙花一现

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

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

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

呵呵

作者: key 时间: 2-12-2009 10:51
你说的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 时间: 2-12-2009 10:53
使用JS的Ajax已经在失势了。没啥可讨论的。
大家往前看，看看JSF，还有RIA吧。

作者: sliuhao 时间: 2-12-2009 10:58

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

 登录/注册后可看大图

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

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

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

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

呵呵

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

作者: yuba 时间: 2-12-2009 10:59

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

 登录/注册后可看大图

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

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

我有一种找到真理的快感

作者: key 时间: 2-12-2009 10:59
能提供点“失势”证据？比如链接之类？

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

 登录/注册后可看大图

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

作者: sliuhao 时间: 2-12-2009 11:01

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

 登录/注册后可看大图

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

我有一种找到真理的快感

快拍个照！笑一个....

作者: sliuhao 时间: 2-12-2009 11:06

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

 登录/注册后可看大图

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

我有一种找到真理的快感

要不我们也找一盆昙花，或者也搞一个昙花？升升天？
哇，怎么又升天了....

作者: key 时间: 2-12-2009 11:08
Ejb的问题在于too heavy，如果Ejb从一开始就和3.0差不多水平，和POJO更多结合，相信现在就完全不同的东西。
Spring等框架证明了Dependency Injection的意义的确非同少可，Annotation也为Java开发带来另一种生机。
Ajax是一个好的概念，毕竟构建在浏览器上的动态应用是很有意义的。
我所针对的只是这种概念如果还坚持在低层的实现上。
我不是在否定浏览器的动态交互的价值，正是因为我重视这种动态交互的价值，才提出“可能的发展方向”。
而JS目前所扮演的角色以及它自身的不足之处，相信一线开发的程序员比我了解得更多。
我们的观点并没有重大的冲突之处。

原帖由 sliuhao 于 2-12-2009 10:58 发表

 登录/注册后可看大图

这不就是你我这些人的真实写照么？
什么PMP,CMM,SAP,SOA,EJB,AJAX,DW,DM， SSIS....都是过眼云烟，该干什么还是干什么...
你我的价值就是所有人都解决不了的问题，你我能解决，在这些问题面前，给我谈银弹的 ...

作者: mayabin 时间: 2-12-2009 11:11

原帖由 key 于 2-12-2009 10:59 发表

 登录/注册后可看大图

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

证据，链接？不会又让人误认为是布道吧。今天不冷静的人太多。

从做项目的经历来说，我曾经为Domapi,Extjs而欢呼过。但是现在接手的项目，我不会再用它们了。

作者: key 时间: 2-12-2009 11:14
技术讨论，各抒己见，没所谓啦。
布道也好，布路也好，说出来，大家分享就行。
其实我对WEB开发的了解的确很少，我也不是很DEFEND自己的观点，说实在的。

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

 登录/注册后可看大图

证据，链接？不会又让人误认为是布道吧。今天不冷静的人太多。

从做项目的经历来说，我曾经为Domapi,Extjs而欢呼过。但是现在接手的项目，我不会再用它们了。

作者: mayabin 时间: 2-12-2009 11:17

原帖由 key 于 2-12-2009 11:14 发表

 登录/注册后可看大图

技术讨论，各抒己见，没所谓啦。
布道也好，布路也好，说出来，大家分享就行。
其实我对WEB开发的了解的确很少，我也不是很DEFEND自己的观点，说实在的。

我做过的项目很杂，但是主要还是局限在java的Web方面。还是群里气氛好些。

作者: yuba 时间: 2-12-2009 12:09

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

 登录/注册后可看大图

从做项目的经历来说，我曾经为Domapi,Extjs而欢呼过。但是现在接手的项目，我不会再用它们了。

很想听听这里的故事

用起来往往就不想欢呼了，这就是我建议的：多一些使用者，少一些布道者

sliuhao兄说的政客是只欢呼不使用，所以能呼很久

作者: 周星星1832 时间: 2-12-2009 12:55

原帖由 key 于 2-12-2009 11:08 发表

 登录/注册后可看大图

Ejb的问题在于too heavy，如果Ejb从一开始就和3.0差不多水平，和POJO更多结合，相信现在就完全不同的东西。
Spring等框架证明了Dependency Injection的意义的确非同少可，Annotation也为Java开发带来另一种生机。
...

JS，ajax 的魅力就在于动态交互，尤其是和CSS的共同使用,可以营造出和非web applications 的一样的界面。

目前流行的js framework源泉就是基于此。
拿jquery举例子，各种plugins使得现在的web界面更加动态，友好。

要说不足，不是js本身的不足，而是浏览器的问题。各种浏览器造成的问题比js自身的问题更大。

要说消亡，需要消亡的是各种浏览器的差异，业界需要统一的标准

作者: MacroJ 时间: 2-12-2009 14:08
一个用超级旧技术的人

作者: mayabin 时间: 2-12-2009 14:22

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

 登录/注册后可看大图

很想听听这里的故事

用起来往往就不想欢呼了，这就是我建议的：多一些使用者，少一些布道者

sliuhao兄说的政客是只欢呼不使用，所以能呼很久

大家想听，我就说说。
我曾经做过一个Web的ERP系统，刚开始使用了DOMAPI开源组件库，我加拿大一个同事是这个项目的贡献者之一。这老兄Javascript巨牛，遇到js问题，我们都问他。即使是最底层的代码，不会超过10分钟，他就能帮你找到问题的根源。
对我个人来说，js就像噩梦。而且就我个人观点，在MVS框架中，View层算是这其中分量最轻的一层，而且JS也仅仅是View层众多实现方式中的一种。如果把大量开发时间放在这一层，没有必要，而且对整个application来说，会有头重脚轻的感觉。试想一个头重脚轻的人，会跑多远？
使用domapi出现了几个问题，使得我们后来把所有代码都迁移到了Extjs。最主要的原因是domapi这个项目的贡献者很少，所以他能提供的组件库以及功能都有限，比如IE和Firefox的兼容性，没有分页的ListGrid等等。
在迁移的过程中，我对Extjs有了些了解。更多的组件库，更好的浏览器兼容性，使得我们最后把产品交付到了客户手中。

项目完成后，我有了一些思考，确实js的Ajax技术给项目添加了活力，比如异步传输，良好的交互性， js在客户端运行减轻了服务器压力。但是它确实也给项目带来了更多的工作量，我们不得不在Java和javascript两端写更多的代码来做接口，尤其是当你的js功力还不够强的情况下。还有一件事让我对js不放心，我提到的那个js大牛，曾经给我们演示过，在地址栏输入js代码，控制程序运行。

所以，对于分层的企业应用程序，我理想中的View层技术，应该有以下特点：
1. 开发简单，最好和control层一种语言。
2. View层的模型最好和Model层的模型一致，这样可以减少转接口。
3. 保证安全性。View层只用来显示，不参与任何逻辑。

这些是我对企业应用程序的View层的要求，如果你打算做网页开发，不适用。

我查过一些资料，JSF，ZK以及Portal技术，能满足我的一些想法，但是我一直没有机会在正式项目中使用。我现在做得项目是Mainframe和java，没有Web。
但是我自己利用业余时间在做一个ZK的项目， Business和Data已经做完了，Web这块刚开始，因为ZK是新手，做的比较慢。希望它不会让我失望。如果它不合适的话，我就再换一个，反正Business这块的接口已经做好了，Web这边只要调用就行。

作者: GateW 时间: 2-12-2009 16:32

原帖由 lufumin1832 于 2-12-2009 12:55 发表

 登录/注册后可看大图

JS，ajax 的魅力就在于动态交互，尤其是和CSS的共同使用,可以营造出和非web applications 的一样的界面。

目前流行的js framework源泉就是基于此。
拿jquery举例子，各种plugins使得现在的web界面更加动态，友 ...

同意，但是浏览器版本的不同也很有乐趣，应该说还是有技术含量的，都统一了也没劲了。

客户端的东西本来就是用来做客户端的事，市场不是由谁会不会来决定的，而是在于这个技术有多少追谁者和市场占有率。

微软也不可能把别人都杀光了，跟着他眼睛还是要看别的。Ajax 的流行很大程度上因为 web 软件本身和最终用户的交互，一个好的 UI/UX 设计者不会极限于使用什么技术，最终的目的还是要提供给用户一个超爽的体验。

作者: 周星星1832 时间: 2-12-2009 20:18

原帖由 mayabin 于 2-12-2009 14:22 发表

 登录/注册后可看大图

大家想听，我就说说。
我曾经做过一个Web的ERP系统，刚开始使用了DOMAPI开源组件库，我加拿大一个同事是这个项目的贡献者之一。这老兄Javascript巨牛，遇到js问题，我们都问他。即使是最底层的代码，不会超过10分 ...

还有一件事让我对js不放心，我提到的那个js大牛，曾经给我们演示过，在地址栏输入js代码，控制程序运行。
??????

作者: woodheadz 时间: 2-12-2009 20:21
感觉楼主标题过于耸人听闻了。
目前各个浏览器厂家都在积极改进JS的运行效率，JS开发工具和JS语言本身都在不断的发展，微软的VS2008开始就能调试JS脚本了。就开发难度而言，JS一样能写出还不错的OO代码来，如果掌握了JS和OO，构建复杂的应用成本也不见得比其它语言高多少。长久看来，我觉得JS更有可能是逐步进化成几种主要开发语言之一。
Flash现在是很牛啊，但Adobe在技术方面就不咋地了。
我个人还是比较看好M$的Silverlight，刚好我在Flash和Silverlight下都做过不少东西，把着两个平台那出来比一下，无论是开发工具、开发语言、程序模型和基础类库等哪一方面，M$都算是完胜。Silverlight缺的只是装机量和使用人群而已，以M$一贯死缠烂打的作风，恐怕当年IE和Netscape的那一幕又会在Silverlight和Flash之间重演。

作者: yuba 时间: 2-12-2009 21:25
标题: 回复 #42 lufumin1832 的帖子
搜狗的云输入法就是这样

作者: lanxuan0552 时间: 2-12-2009 22:52
很有启发.
JS开发确实很慢， Jquery好一点。但还是很慢，用ms的ajax toolkits就很快了。
真正用js开发的web很少的，就好像直接用汇编写应用一样。
Silverlight 是我看好的。

作者: GateW 时间: 3-12-2009 08:44

原帖由 lanxuan0552 于 2-12-2009 22:52 发表

 登录/注册后可看大图

很有启发.
JS开发确实很慢， Jquery好一点。但还是很慢，用ms的ajax toolkits就很快了。
真正用js开发的web很少的，就好像直接用汇编写应用一样。
Silverlight 是我看好的。

我觉得JS是很有前途的，Silverlight再等等看，前途不明朗。不是每个人都愿意安装插件，况且 IE8 的水准真的很欠缺，在浏览器市场这块，微软不占优势。用其他浏览器的谁愿意无聊的装那个？

Google 和 Yahoo 等等已经开始让 JS 编译后执行了，据说效率是以前的8倍。作为脚本语言，JS其实很简单，灵活，与 html, css 相辅相成，又继承了 web 开发的传统，同时跨平台的兼容性又好，应该说还是未来很长一段时间的主流。

MS Ajax toolkits 不是轻量级的，效率可想而知，不过对于“菜鸟级”应用还是合适的。

用JS开发的web application，尤其是类似 windows 体验的，比比皆是，哪里少了？

个人以为，网站和 web 应用也再分化，网站多选择 php+flash，应用的平台选择很广，但是目前谁也离不开JS

作者: GateW 时间: 3-12-2009 08:52

原帖由 yuba 于 2-12-2009 21:25 发表

 登录/注册后可看大图

搜狗的云输入法就是这样

那是它自己的网站吧？用JS注入的木马和病毒也是很多的，不过需要一些功底。JS 比起插件相对来说 JS 是安全的。

作者: key 时间: 3-12-2009 09:23
“Google和Yahoo让JS编译后执行”这个信息能否给个链接证实一下？谢谢。

ie这两年的发展和vista一样不思进取，实在让有难以接受。至于插件，这个很难说，
就看浏览器各种的发展战策如何了。浏览器插件API会越来越放开，使插件提供商自行开发，
如果M$要开发一个技术，我觉得还是会提供相应的插件的。所以在这个方面我反而是最不担心的。

原帖由 GateW 于 3-12-2009 08:44 发表

 登录/注册后可看大图

我觉得JS是很有前途的，Silverlight再等等看，前途不明朗。不是每个人都愿意安装插件，况且 IE8 的水准真的很欠缺，在浏览器市场这块，微软不占优势。用其他浏览器的谁愿意无聊的装那个？

Google 和 Yahoo 等 ...

作者: GateW 时间: 3-12-2009 09:43

原帖由 key 于 3-12-2009 09:23 发表

 登录/注册后可看大图

“Google和Yahoo让JS编译后执行”这个信息能否给个链接证实一下？谢谢。

ie这两年的发展和vista一样不思进取，实在让有难以接受。至于插件，这个很难说，
就看浏览器各种的发展战策如何了。浏览器插件API会越来越 ...

Google V8 Engine - http://code.google.com/apis/v8/intro.html

You can find - V8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs.

FYI - http://www.geekpolice.net/cool-l ... ance-test-t5516.htm

作者: yuba 时间: 3-12-2009 10:06

原帖由 GateW 于 3-12-2009 08:52 发表

 登录/注册后可看大图

那是它自己的网站吧？

我只是举个例子说明那个js大牛做的事情

不涉及是自己的网站还是别人的网站

作者: 清风不写字 时间: 3-12-2009 10:23
Flash的Action script 编辑器，那叫一个烂。

作者: finaleden 时间: 4-12-2009 17:16
楼主说自己不懂ajax果然不是谦虚。

连ajax和JavaScript的关系都没弄明白就说ajax已死，有意思。

只纠正两点：
第一：jQuery是JavaScript框架，而不是ajax框架。
第二：ajax更多的是一种思想，即富客户端，也就是客户端计算，针对的是传统的所有运算都放在服务器端计算，而完全不利用本地计算资源的web应用。拿你第一楼举的例子来说，如果这个应用有很多人用，那你一台服务器最多能承受多大的压力？可是如果视频转换的步骤能由本地资源来完成，你一台服务器能承受的压力恐怕就要比原来大得多吧？

作者: syfool 时间: 4-12-2009 21:17
提示: 作者被禁止或删除, 无法发言 AJAX关键要看用在哪里。用对了地方，就是好东西；用错了地方，就是垃圾。

ajax，我接触过，但没有做深入的技术了解。就其设计思想而言，我觉得最适合服务器端并发量很大的应用。由于国内人口众多，所以我一直认为ajax在国内流行还是有道理的。

作者: mimel 时间: 4-12-2009 21:58
工作了快10年，除了C语言，其它什么都不会。感慨一下，技术更新太快，想跟但力不从心，每次书都只看到一半就继续不下去了。

作者: key 时间: 5-12-2009 12:32
想请教一下，现在哪一个AJAX应用能实现利用本地资源进行“视频转换”？

如果我的理解不错，象“视频转换”这类东西，在AJAX应用框架里，应该是服务器一端的任务。

AJAX是一种Rich Client，这一点相信很多人都明白。
所以，利用AJAX进行B/S开发，已不是6年前或更早以前的B/S开发中提出的瘦客户端的概念。
而C/S则是这种富客户端的最早提倡者，后来B/S的出现，理论上大肆否定这种富客户端，
我相信很多人也是知道的。现在由后来的瘦客户端又走回原来的富客户端，但这个过程中却让客户端的开发
达到了前所未有的难度，这就是我提出值得思考的地方。

这种“难”起因于两点：一是大家要避开OS层的束缚，让应用建立在比OS更高层的Web Browser；
二是原来的C/S存在C端下载的问题，利用Web进行运行时下载，用户在任何时候都用到最新版本的程序。

所以我的论证的出发点就是“到底这种难是否值得”，而不是“我们还要不要富客户端”。我是认为，
作为一种更好的用户体验，富客户端程序，以及快速响应网页，都是受用户欢迎的。如果只是要求快速响应网页，
象DWR这种响应框架是很不错的。只是我们似乎越走越远，在Browser范围内，我们已经开发全面模拟原来的C端。
而这种路应该怎样走，下一步会去哪里，就是我提出的问题。

原帖由 finaleden 于 4-12-2009 17:16 发表

 登录/注册后可看大图

楼主说自己不懂ajax果然不是谦虚。

连ajax和JavaScript的关系都没弄明白就说ajax已死，有意思。

只纠正两点：
第一：jQuery是JavaScript框架，而不是ajax框架。
第二：ajax更多的是一种思想，即富客户端，也 ...

作者: finaleden 时间: 27-12-2009 13:02

原帖由 key 于 5-12-2009 12:32 发表

 登录/注册后可看大图

想请教一下，现在哪一个AJAX应用能实现利用本地资源进行“视频转换”？

如果我的理解不错，象“视频转换”这类东西，在AJAX应用框架里，应该是服务器一端的任务。

AJAX是一种Rich Client，这一点相信很多人都明 ...

视频的话目前只能借助flash，applet

作者: black_zerg 时间: 31-12-2009 22:56
提示: 作者被禁止或删除, 无法发言 don't agree. Personally I like swing more, but JavaScript won't die soon.
The fact is, because of the market and the competition of those big companies, JavaScript is becoming the most popular and cross-platform language. Now if we want to play with RIA, Rich JavaScript framework is something we must learn and master.

JQuery is even simpler than JavaScript itself. it can be used to enhance web page, it has so many plugins and fits web page requirements, it will never die. other heavier frameworks like ext-js can create very complicated enterprise level application. GWT maybe attractive to Java developer, i tried some small projects with it. Now I prefer native JavaScript way because that's more flexible and extensible.

Now the JavaScript engine is becoming so fast and some people believe JS is better than Java. I can't tell which is better. What I can tell is they are all easy to learn.

Recently i found Qooxdoo is very interesting. it's based on a nice OOP design. So you can create you classes and widgets through an elegant way.

And what I would like to point out is, AJAX has been thriving since 2005. My guess will be the server assisted MVC like struts will die. JSF2 is coming, probably still a rubbish one.

[ 本帖最后由 black_zerg 于 31-12-2009 23:16 编辑 ]

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/ibbs/)