jQuery 让人恋恋不舍的秘密
jQuery 将马上发布 1.4 正式版,代码也从 googlecode 上迁移到了 github. jQuery 是我接触的第一个 JS 类库,俗话说初恋总是让人难以忘记。一年以前,这种难以忘记仅仅是一种纯感觉,说不出来具体原因。前几天重新看了一遍 github 上的源码。从纯功能上说,jQuery 并没有特别出色的地方。究竟是什么让我如此恋恋不舍呢?
昨天搭建 taskspeed, 检查 jQuery 的测试代码时,突然明晓了一个也许大家都已知道的秘密:
jQuery 最出色最让人恋恋不舍的是它的 API 设计。
比如 dom-style 的 api, YUI3 和 MooTools 等框架采用的是传统方式:
el.setStyle(prop, val);
el.getStyle(prop);
el.setStyles({ propA: valA, propB: valB });
el.getStyles(propA, propB); // MooTools 支持
在 jQuery 里,一个 css 方法全部搞定:
el.css(prop); // 表示 getStyle
el.css(prop, val); // 表示 setStyle
el.css({ propA: valA, propB: valB }); // 表示 setStyles
el.css(prop, func); // func 是一个返回 val 值的函数
对比以上两种 API 设计,乍一看 jQuery 显得不那么“标准”。但从可记忆性和灵活性上讲,我觉得 jQuery 的设计都更人性化。jQuery 的 API 还符合学习上的渐进式思维:先学会最简单的情况el.css(prop), 再了解到还可以有两个参数,接着发现参数可以是 map, 更进一步发现 val 还可以是一个函数。func 参数甚至能带给学习者一种惊喜:居然还可以这样用!jQuery 把一种渐进和愉悦带进了学习和使用的过程中,实在漂亮!
YUI3 的 API 缺少这种乐趣。查询 jQuery 的 API, 会有一种探寻秘密的寻宝感觉。YUI 的文档查询则让人感觉就是份工作,有点 boring.
和 YUI2 相比,YUI3 的 API 做了些改变。在 YUI2 里,YAHOO.util.Dom 的方法名,严格以动词开头,虽然有些方法名长点,但总体规律性很强,可记忆性还不错。在 YUI3 里,则出现了 byId, elementByAxis 等方式命名的方法。纯粹为了省几个字符?这种不一致性很纳闷。还有一些以名词命名的方法:ancestor, docHeight, 乍一看很难以为是方法。
老婆说,要睡觉了,就不码字了。最后说一句:YUI3 的 API 整体还是挺不错的,比如 Node 的方法命名,就非常严谨。ancestor 也是为了对应 next, prev 等命名。也就是说:Y.Dom 其实已变成了内部 API, 不鼓励用户直接调用。
但是不知为什么,我还是觉得 jQuery 的 API 设计高出一个层次,套用一句流行话就是:
jQuery API 的用户体验更好。

January 13th, 2010 on 0:11
jq的这一点做得的确比较好,而且在命名上也比较符合一般用户的思维,少了一些程序员的术语.
January 13th, 2010 on 7:22
喜欢jq,已经把我惯得不想看别的库了
January 13th, 2010 on 7:36
老婆,一起来看jQuery的API啊。。
January 13th, 2010 on 9:15
确实是这样,
应该说对于熟悉css的前端工程师来讲jquery操作起来是非常顺手的,
选择器综合了css2,css3的很多东西,方便而强大,
各种dom操作,无论是拼写还是调用方式,
都是比较简单的,没有让你有多余的思考,
如果说哪个库比哪个库好的话,这很不好说,
出发点不同,jq在js领域的综合使用上有时还会让你觉得有些不足,
但如果也讲用户体验的话,jq无疑是现在做的最好的,
就好象诗词,人人都知道李煜的词好,也脍炙人口,
但人人能背出来的估计都是像静夜思这样的东西,
简易的深刻是一种水平,是一种境界
January 13th, 2010 on 9:21
jq体现的就是很KISS的感觉,简单实用,高效简洁,他只对脚本做一层统一封装,有点类似C对汇编的封装,目的是为了让js更容易用,而解决jq的弱架构要靠其他力量。
而YUI从一开始就不是走这条路,Y总企图通过脚本本身解决一切问题,Y的核心目的是让js容易管理,看似完美的架构之外,回避了无数看客。
January 13th, 2010 on 9:57
是pattern matching,基于消息的函数调用经常使用这样的模式。因为jQuery的functional风格,所以它使用了pattern matching来收紧api数量,效果很不错。
但是上次mootools的开发者说过jQuery的这种设计也意外的鼓励了一次使用就抛弃的代码风格,容易造成你写只为一个页面而作的代码段。这对于鼓励前端开发减少代码重复不利,从长期来看,由于js还不支持原生的pattern matching,所以jQuery这种方式也能由于api灵活降低一些代码的可读性。
January 13th, 2010 on 10:12
最后一句是亮点:jQuery API 的用户体验更好。
Apple的用户体验更好,google的的用户体验更好,wave的用户体验更好,XXXXX的用户体验更好。
January 13th, 2010 on 10:36
抱歉,我有些不同的看法。
灵活与笨重其实是把双刃剑,规模越大、协作越多、复杂度越高的时候,反而是越笨拙越好。YUI它的设计初衷应该和Jq不同吧,就比如那个方法的参数是否应该顶死数量、类型一样。java之所以适应大规模也在于其足够“死板”,方法的参数类型就是死的,最多为了灵活度有了方法重载,但不会存在一个方法名同时又有不同类型又有不同数量还有不同功能的情况,给别人接口的时候会乱的。
就像那个setStyle和setStyles的区别,可能跟我学习编程时就从传统OOP语言起步有关,我更喜欢严谨的做法,而不是一个css里根据参数不同来功能不同的变化。
January 13th, 2010 on 10:43
其实回顾jquery的历史,它一开始是定位給设计师用的,所以api很语义。而YUI一开始定位是在不污染原生对象的基础上建一个标准化的api层,它的消费对象是开发者,所以保留了很多术语。
可能我用jquery的时间短,它一会返回原生对象一会返回包装后的对象,让我不适应。
January 13th, 2010 on 13:01
挑个刺 :)
el.css({ propA: valA, propB, valB }); // 表示 setStyles
这里的 propB, valB 应该是 propB: valB 吧
January 13th, 2010 on 19:42
jquery对于像我这样从CSSer像前端转的人来说,比其它框架确实更容易接受,YUI其实一直想看看,只是苦于中文文档太少,英文看起来实在太吃力
January 13th, 2010 on 20:42
不论是在yahoo,还是在taobao,伴随着yui的成长一路走来,从他身上学到了好多好多,总有一种割舍不下的感情……
January 13th, 2010 on 21:23
设计库的时候一律加一个API层,想咋调用就咋调用
January 13th, 2010 on 23:46
@kejun
quote: 可能我用jquery的时间短,它一会返回原生对象一会返回包装后的对象,让我不适应。
呃,jQuery返回的操作对象啥米时候有了原生对象了歪?除了经过类似于get(n)一类的转换方法外,它返回的几乎都是包装后的对象的吧。
January 14th, 2010 on 8:45
特地前来围观JQ的API
January 14th, 2010 on 11:00
恩,这个是关键,还有一个关键点在于,用jQuery时的思维方式,你总能找出更好的方法还做,总是能给你一种开发的冲动,用更加灵活的方式去开发。这是一个大家都知道的秘密,呵呵。
January 16th, 2010 on 11:57
大胆预测下JS框架的走势
MooTools将在接下来的几年内像jQuery一样迅速走红
而jQuery则会慢慢销声匿迹
YUI将不尴不尬的活着,YUI 3.x将成为小部分人的玩物,大部分人的忽视物
Ext将在web app应用中有一番作为
http://www.javaeye.com/topic/245057
January 17th, 2010 on 8:35
@andy_ah: 预测的目的不是准确,而是思考。
January 17th, 2010 on 20:06
前段时间正准备学习MooTools….感觉确实没有jquery容易上手啊..
January 18th, 2010 on 12:46
您说出了隐藏我内心多年的秘密~~~
泪牛满面中。。。。。。。。
January 19th, 2010 on 23:12
jQuery和页面结合的非常好。但是要做大点的东西,想要引入一些面向对象的方式来管理和编写代码就不适合了。jQuery的api的确让人依恋,它让jQuery容易上手,相对应的我在已用MooTools做了一个产品后仍然感到不熟悉它的api,不过MooTools的“类”设计地同样让人依恋。
January 20th, 2010 on 14:02
看了这页面,这内容又让我恢复了做前端的热情.
January 21st, 2010 on 15:58
JQ有点渐进增强~
YUI? 我们正在用~
是2.8
January 21st, 2010 on 17:20
jQuery主版本更新这么快,很多插件跟不上,这点很让人担心。
January 22nd, 2010 on 11:27
引用:ven
‘正好淘汰一些过时插件’
希望雕兄那天把kissy一套组建,在用jquery写下。我在web项目中以jq为js核心库,然后引用很多雕兄的组建,就多了很多js。。真希望有jq的一套。。期待!!!!
本人搞搞程序,但是jq用的忒熟悉了。其他都不忒能接受!!也没撒精力搞js。。
January 22nd, 2010 on 20:22
YUI 的文档查询则让人感觉就是份工作。
经典中的经典。
January 24th, 2010 on 12:47
简单就是美,YUI api太过于正规,jQuery一个api可以包含多种写法,入门简单
假若一个api能做的事情被划分为多个api来完成,那么给人感觉那个api就是万能api,人们乐于讨论讨论这个api.
而且jQuery这么多插件,和一些奇怪的写法总是能给人们带来惊喜.
但话说回来,在设计较为复杂的组件,jQuery很难做到面向对象这一特点,后期难维护.
可以说jQuery给浏览器打了一个通用的补丁,消除了浏览器兼容性等问题,提升了开发体验,一个$(xx).xx()给人以无限遐想.
我相信dojo也做的非常好,还有就是UI组件部分,作为专业前端开发人员,你愿意用里面的组件吗?同一套风格,不变的组件功能,难以扩展,用了还体现不出自己网站的设计风格,还与网站本身的需求有一些出入,难以控制,还不如自己写一个,呵呵。
不同框架做不同事,还有个人喜欢不同,但我想技术人员都是追求卓越的.个人之见:)
January 24th, 2010 on 21:47
最近强迫自己开始学习yui2,但发现这好像是专为js功力较深的人准备。
我现在只会用原生的getElementById这些DOM,对jquery比较熟悉,也能完成一些基础的交互和组件制作,并能考虑到重用性和html的分离,突然用yui来模拟以前的程序,似乎无从下手。我以为加载了dom.js,就能很方便的操作dom了,但总是提示这里那里出错,汗。。。。。yui的各种js文件分类倒是详细,可我却不知道再怎么组织起来了。
比如dom.js和event.js,我以为同时加载后就能替代 yahoo-dom-event.js,可不行。
博主有些什么好的建议么?可否有什么好的建议呢?我必须学yui2了,为来年的工作做准备。
yui2看的我一头雾水。
January 24th, 2010 on 21:51
我现在只会用原生的getElementById这些DOM
这句话说错了,请删除之,应该是:
我现在只会用原生的getElementById这些方法来操作DOM
January 24th, 2010 on 22:52
@yoom: 从基础学起,建议看 YUI 官方的文档,一步一步学习。
January 27th, 2010 on 11:36
“老婆说,要睡觉了,就不码字了”这个不要往外说哦
^v^.
February 5th, 2010 on 22:49
Jq确实很强大,刚接触就被它的独特之处吸引了,强大的选择器,让你很轻松的控制页面上的每个元素变化。
February 18th, 2010 on 10:18
我觉得正是因为jQuery的API如此强大,导致它的源代码过于复杂,比较难读。JS又没有方法重载这一说,又要处理很多不同种参数的情况。
还有jQuery写扩展写组件比较不爽,要去遵守它的一些规定,比如方法必需返回jQuery对象以便链式调用。就为了这个链式调用,还要pushStack之类的操作。
还有,jQuery里一切都是jQuery对象,但不同的html元素适用的方法又不同,这又导致了在写一些方法的开头,总要去判断一些东西,例如元素标签之类的……
总之,我觉得jQuery也就是用起来很爽,读代码和写扩展非常的不爽。
February 19th, 2010 on 19:30
@yuan: 目前 jquery 在 github 上的源码阅读起来挺清爽,并不复杂。
leave a reply