|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-09-09
差沙 写道 radar 写道 ui在ajax lib选择时很重要。如果yui-ext的ui做了不好，估计根本没有现在的光景。借了yui的光，现在还自立门户。呵！
YUI-EXT的成功也就在ui上。你们认为呢？ 另外mootools的命名不是很好，为什么不用package的概念呢？ 我不这么认为，说明你还没有深入了解EXT 那你最常用的yui-ext的功能是什么呢？说来看看， 写一些代码也行？ 别只下结论而不说论据啊！ |
| 返回顶楼 | |
|
发表时间：2007-09-10
radar 写道 fins 写道 "另外mootools的命名不是很好，为什么不用package的概念呢？"
因为他不想成为 又一个dojo 又一个yui吧 毕竟简单轻巧才是他最求的吧. 其实我觉得JS里搞命名空间实际意义不是很大 至少现在看来是这样. 因为我们一般很少会写太过复杂的js代码,而且很少会在同一个页面内同时使用两个以上的大型js框架 package怎么了？dojo的问题是package吗？ 我指的是，mootools占用了太多的顶层变量名。 $extend Ajax $ fx ... ... 万一你不小心定义一个 $开头的变量呢？ 可能这不是主要问题，如果都放到 var mootools={};下就没这个问题了啊！为什么不呢？ 我明白你的意思. 我已经回答这个问题了. prototype也是直接使用顶层的变量名 $ ajax Element等等 以前我写东西也很注意这些,但是后来发现意义不是很大. 1 冲突的概率很小 因为你很少会将多个js框架在同以页面中混合使用 而在每一个方法前加上moo或者mootools会解决一些问题,但是他也带来了麻烦,他解决的问题是不常遇到的,带来的麻烦却是人人都能感受到的. 2 moo或者prototype的作者用意很明显,就是希望让使用者感觉不到js框架的存在,让大家把框架当作js语言本身的一部分. 他们希望通过自己的努力来改变js的开发方式. 3 当一个框架或是语言或是其他什么东西 足够强大足够出色,已经成为事实标准的时候, 使用者是会妥协的. 举一个不太恰当的例子, 你有没有质疑过 "js里为什么不给 function加一个命名空间, 例如 JS.function, 这样我就可以自由的使用 function作为变量名了" 为什么你不会有这样的质疑? 因为他是规定 他是标准, 不喜欢? 那你可以不用js啊. 其实所有这类框架都有一定的排他性. 尤其是jquery prototype moo这类相对低层的js框架, 他们不希望和竞争对手共存. 你有"$()" 那我就要用我自己的 更好的"$()"打败你,道理就是这么简单. 而让各种低层框架能够互相妥协,能够共存是 更上层的框架去做的事, 例如EXT 和他的bridge. 当然,我从来不否认这样做的缺点,但是这些缺点目前看来不是问题的关键. |
| 返回顶楼 | |
|
发表时间：2007-09-10
radar 写道 差沙 写道 radar 写道 ui在ajax lib选择时很重要。如果yui-ext的ui做了不好，估计根本没有现在的光景。借了yui的光，现在还自立门户。呵！
YUI-EXT的成功也就在ui上。你们认为呢？ 另外mootools的命名不是很好，为什么不用package的概念呢？ 我不这么认为，说明你还没有深入了解EXT 那你最常用的yui-ext的功能是什么呢？说来看看， 写一些代码也行？ 别只下结论而不说论据啊！ 是你先下的结论--“YUI-EXT的成功也就在ui上”，而也没有说出论据。 你先说，我就说，哈哈。不要搬石头砸自己的脚哦。 其实没有反对你的意思，我就是觉得，不能把ext跟其他的jslib做比较。你的说法确实对ext有些不公。ext是对底层js lib框架的扩展，扩展的框架已经有很多了。而且现在还有自己的底层实现。 既然是扩展，所以底层jslib实现的功能，ext自然不会去实现，而是做一下封装。所以说ext本质上跟其他的jslib就不是一回事。当然不否认ext的最大亮点是在UI上，其他的好像没有什么出彩的。那是因为，其他底层的机制很大一部分就是对其他jslib的调用(ext自己的底层也可看成对自己的扩展)。 |
| 返回顶楼 | |
|
发表时间：2007-09-10
引用 ui在ajax lib选择时很重要。如果yui-ext的ui做了不好，估计根本没有现在的光景。借了yui的光，现在还自立门户。呵！
YUI-EXT的成功也就在ui上。你们认为呢？ “jQuery最大的优点是易用。 jQuery可以一行代码搞掂很多问题。 YUI最大的优点是它被设计为面向对象的（object oriented）和组件的架构（component architecture）。” 《EXT设计模式初学习》 http://www.iteye.com/topic/121946 |
| 返回顶楼 | |
|
发表时间：2007-09-10
"jQuery可以一行代码搞掂很多问题"
这个举两例呗 我没有认真研究过jquery 很多问题都理解的不到位 例如"jQuery可以一行代码搞掂很多问题" 具体怎么搞定呢? 我觉得 一行代码搞定很多问题 的关键不是代码怎么写 而要看 那很多问题是什么问题. |
| 返回顶楼 | |
|
发表时间：2007-09-10
嘻嘻～问Jack～小弟也没怎么接触过jq
|
| 返回顶楼 | |
|
发表时间：2007-09-10
现在js也用上很多设计模式的理念了。
就把“搞掂很多问题”的问题交给“设计模式”吧 |
| 返回顶楼 | |
|
发表时间：2007-09-10
呵呵
"jQuery可以一行代码搞掂很多问题" 还有他那句著名的 write less,do more. 似乎都在告诉人们 jquery能很简单的搞定很多事情. 但是问题是 jquery能, 别的js框架也能啊 其实对于绝大多数的常用的情形,单纯从使用角度来讲, 那些js框架都差不多. 要比拼的还是内在的代码设计 效率 以及一些辅助功能等. 在这些方面 jquery并没有绝对优势. 个人看法,而且我承认对jquery不了解. 当然我不是 "反jquery派",我只是找不到足够好的理由可以说服我自己去使用jquery 而放弃熟悉的prototype或者是放弃优秀的mootools. |
| 返回顶楼 | |
|
发表时间：2007-09-10
其实都怪我带着大家跑题了！
我的意思不是否定什么，推荐什么，我的出发点是从lib本身特性来讨论。指出某个lib可能有的问题是为了大家去避免它。例如：package的问题，用mootools开发的系统交付给用户肯定会没问题的，因为你既然使用的mootools肯定会避免这个问题，遇到变量重复，代码也不会测试通过。但指出来不一定要求作者改或和你争论。也只是提出问题罢了！ |
| 返回顶楼 | |
|
发表时间：2007-09-10
其实比较好的做法是 moo还是提供一个命名空间
例如 moo.Ajax moo.$extend..... 然后自己再做一个桥 把这些东西挂到window的根上. 例如 Ajax=moo.Ajax $extend=moo.$extend... 当开发者不希望moo的东西都挂到window下时,可以不引入那个桥 |
| 返回顶楼 | |
