【转】jQuery中的编程范式

原文地址：http://www.iteye.com/topic/1119283

     浏览器前端编程的面貌自2005年以来已经发生了深刻的变化，这并不简单的意味着出现了大量功能丰富的基础库，使得我们可以更加方便的编写业务代码，更重要的是我们看待前端技术的观念发生了重大转变，明确意识到了如何以前端特有的方式释放程序员的生产力。本文将结合jQuery源码的实现原理，对javascript中涌现出的编程范式和常用技巧作一简单介绍。
  
1. AJAX: 状态驻留，异步更新 
    首先来看一点历史。
A. 1995年Netscape公司的Brendan Eich开发了javacript语言，这是一种动态(dynamic)、弱类型(weakly typed)、基于原型(prototype-based)的脚本语言。
B. 1999年微软IE5发布，其中包含了XMLHTTP ActiveX控件。
C. 2001年微软IE6发布，部分支持DOM level 1和CSS 2标准。
D. 2002年Douglas Crockford发明JSON格式。
至此，可以说Web2.0所依赖的技术元素已经基本成形，但是并没有立刻在整个业界产生重大的影响。尽管一些“页面异步局部刷新”的技巧在程序员中间秘密的流传，甚至催生了bindows这样庞大臃肿的类库，但总的来说，前端被看作是贫瘠而又肮脏的沼泽地，只有后台技术才是王道。到底还缺少些什么呢？
     当我们站在今天的角度去回顾2005年之前的js代码，包括那些当时的牛人所写的代码，可以明显的感受到它们在程序控制力上的孱弱。并不是说2005年之前的js技术本身存在问题，只是它们在概念层面上是一盘散沙，缺乏统一的观念，或者说缺少自己独特的风格, 自己的灵魂。当时大多数的人，大多数的技术都试图在模拟传统的面向对象语言，利用传统的面向对象技术，去实现传统的GUI模型的仿制品。
     2005年是变革的一年，也是创造概念的一年。伴随着Google一系列让人耳目一新的交互式应用的发布,Jesse James Garrett的一篇文章《Ajax: A New Approach to Web Applications》被广为传播。Ajax这一前端特有的概念迅速将众多分散的实践统一在同一口号之下，引发了Web编程范式的转换。所谓名不正则言不顺，这下无名群众可找到组织了。在未有Ajax之前，人们早已认识到了B/S架构的本质特征在于浏览器和服务器的状态空间是分离的，但是一般的解决方案都是隐藏这一区分，将前台状态同步到后台，由后台统一进行逻辑处理，例如ASP.NET。因为缺乏成熟的设计模式支持前台状态驻留，在换页的时候，已经装载的js对象将被迫被丢弃，这样谁还能指望它去完成什么复杂的工作吗？
     Ajax明确提出界面是局部刷新的，前台驻留了状态，这就促成了一种需要：需要js对象在前台存在更长的时间。这也就意味着需要将这些对象和功能有效的管理起来，意味着更复杂的代码组织技术，意味着对模块化，对公共代码基的渴求。
     jQuery现有的代码中真正与Ajax相关（使用XMLHTTP控件异步访问后台返回数据）的部分其实很少，但是如果没有Ajax, jQuery作为公共代码基也就缺乏存在的理由。

2. 模块化：管理名字空间 
     当大量的代码产生出来以后，我们所需要的最基础的概念就是模块化，也就是对工作进行分解和复用。工作得以分解的关键在于各人独立工作的成果可以集成在一起。这意味着各个模块必须基于一致的底层概念，可以实现交互，也就是说应该基于一套公共代码基，屏蔽底层浏览器的不一致性，并实现统一的抽象层，例如统一的事件管理机制等。比统一代码基更重要的是，各个模块之间必须没有名字冲突。否则，即使两个模块之间没有任何交互，也无法共同工作。
     jQuery目前鼓吹的主要卖点之一就是对名字空间的良好控制。这甚至比提供更多更完善的功能点都重要的多。良好的模块化允许我们复用任何来源的代码，所有人的工作得以积累叠加。而功能实现仅仅是一时的工作量的问题。jQuery使用module pattern的一个变种来减少对全局名字空间的影响,仅仅在window对象上增加了一个jQuery对象(也就是$函数)。
     所谓的module pattern代码如下，它的关键是利用匿名函数限制临时变量的作用域。

  js本身缺乏包结构，不过经过多年的尝试之后业内已经逐渐统一了对包加载的认识，形成了RequireJs库这样得到一定共识的解决方案。jQuery可以与RequireJS库良好的集成在一起, 实现更完善的模块依赖管理。http://requirejs.org/docs/jquery.html

  通过以下函数调用来定义模块my/shirt, 它依赖于my/cart和my/inventory模块，

3. 神奇的$：对象提升 
      当你第一眼看到$函数的时候，你想到了什么？传统的编程理论总是告诉我们函数命名应该准确，应该清晰无误的表达作者的意图，甚至声称长名字要优于短名字，因为减少了出现歧义的可能性。但是，$是什么？乱码？它所传递的信息实在是太隐晦，太暧昧了。$是由prototype.js库发明的，它真的是一个神奇的函数，因为它可以将一个原始的DOM节点提升(enhance)为一个具有复杂行为的对象。在prototype.js最初的实现中，$函数的定义为

但是使用$之后，却随处可见如下的写法

id与element之间的距离似乎被消除了，可以非常紧密的交织在一起。
  prototype.js后来扩展了$的含义，

  这对应于公式

  很遗憾，这一步prototype.js走偏了，这一做法很少有实用的价值。
  真正将$发扬光大的是jQuery, 它的$对应于公式

  这里有三个增强
  A. selector不再是单一的节点定位符，而是复杂的集合选择符
  B. 返回的元素不是原始的DOM节点，而是经过jQuery进一步增强的具有丰富行为的对象，可以启动复杂的函数调用链。
  C. $返回的包装对象被造型为数组形式，将集合操作自然的整合到调用链中。

  当然,以上仅仅是对神奇的$的一个过分简化的描述,它的实际功能要复杂得多. 特别是有一个非常常用的直接构造功能.

  jQuery将根据传入的html文本直接构造出一系列的DOM节点,并将其包装为jQuery对象. 这在某种程度上可以看作是对selector的扩展: html内容描述本身就是一种唯一指定. 
     $(function{})这一功能就实在是让人有些无语了, 它表示当document.ready的时候调用此回调函数。真的，$是一个神奇的函数, 有任何问题，请$一下。
     总结起来, $是从普通的DOM和文本描述世界到具有丰富对象行为的jQuery世界的跃迁通道。跨过了这道门，就来到了理想国。
   
4. 无定形的参数：专注表达而不是约束 
     弱类型语言既然头上顶着个"弱"字, 总难免让人有些先天不足的感觉. 在程序中缺乏类型约束, 是否真的是一种重大的缺憾? 在传统的强类型语言中, 函数参数的类型,个数等都是由编译器负责检查的约束条件, 但这些约束仍然是远远不够的. 一般应用程序中为了加强约束, 总会增加大量防御性代码, 例如在C++中我们常用ASSERT, 而在java中也经常需要判断参数值的范围

     很显然, 这些代码将导致程序中存在大量无功能的执行路径, 即我们做了大量判断, 代码执行到某个点, 系统抛出异常, 大喊此路不通. 如果我们换一个思路, 既然已经做了某种判断,能否利用这些判断的结果来做些什么呢? javascript是一种弱类型的语言,它是无法自动约束参数类型的, 那如果顺势而行,进一步弱化参数的形态, 将"弱"推进到一种极致, 在弱无可弱的时候, weak会不会成为标志性的特点? 
  看一下jQuery中的事件绑定函数bind, 
   A. 一次绑定一个事件 $("#my").bind("mouseover", function(){});
   B. 一次绑定多个事件 $("#my").bind("mouseover mouseout",function(){})
   C. 换一个形式, 同样绑定多个事件 
      $("#my").bind({mouseover:function(){}, mouseout:function(){}});
   D. 想给事件监听器传点参数
      $('#my').bind('click', {foo: "xxxx"}, function(event) { event.data.foo..})
   E. 想给事件监听器分个组
      $("#my").bind("click.myGroup″, function(){});
   F. 这个函数为什么还没有疯掉???
   
   就算是类型不确定, 在固定位置上的参数的意义总要是确定的吧? 退一万步来说, 就算是参数位置不重要了,函数本身的意义应该是确定的吧? 但这是什么?

   一个函数怎么可以这样过分, 怎么能根据传入参数的类型和个数不同而行为不同呢? 看不顺眼是不是? 可这就是俺们的价值观. 既然不能防止, 那就故意允许. 虽然形式多变, 却无一句废话. 缺少约束, 不妨碍表达(我不是出来吓人的). 
   
5. 链式操作: 线性化的逐步细化 
    jQuery早期最主要的卖点就是所谓的链式操作(chain).

在一般的命令式语言中, 我们总需要在重重嵌套循环中过滤数据, 实际操作数据的代码与定位数据的代码纠缠在一起. 而jQuery采用先构造集合然后再应用函数于集合的方式实现两种逻辑的解耦, 实现嵌套结构的线性化. 实际上, 我们并不需要借助过程化的思想就可以很直观的理解一个集合, 例如 $('div.my input:checked')可以看作是一种直接的描述,而不是对过程行为的跟踪. 
     循环意味着我们的思维处于一种反复回绕的状态, 而线性化之后则沿着一个方向直线前进, 极大减轻了思维负担, 提高了代码的可组合性. 为了减少调用链的中断, jQuery发明了一个绝妙的主意: jQuery包装对象本身类似数组（集合）. 集合可以映射到新的集合， 集合可以限制到自己的子集合，调用的发起者是集合，返回结果也是集合，集合可以发生结构上的某种变化但它还是集合, 集合是某种概念上的不动点，这是从函数式语言中吸取的设计思想。集合操作是太常见的操作, 在java中我们很容易发现大量所谓的封装函数其实就是在封装一些集合遍历操作, 而在jQuery中集合操作因为太直白而不需要封装. 
    链式调用意味着我们始终拥有一个“当前”对象，所有的操作都是针对这一当前对象进行。这对应于如下公式

调用链的每一步都是对当前对象的增量描述，是针对最终目标的逐步细化过程。Witrix平台中对这一思想也有着广泛的应用。特别是为了实现平台机制与业务代码的融合，平台会提供对象（容器）的缺省内容，而业务代码可以在此基础上进行逐步细化的修正，包括取消缺省的设置等。
    话说回来, 虽然表面上jQuery的链式调用很简单, 内部实现的时候却必须自己多写一层循环, 因为编译器并不知道"自动应用于集合中每个元素"这回事.

6. data: 统一数据管理 
     作为一个js库，它必须解决的一个大问题就是js对象与DOM节点之间的状态关联与协同管理问题。有些js库选择以js对象为主，在js对象的成员变量中保存DOM节点指针，访问时总是以js对象为入口点，通过js函数间接操作DOM对象。在这种封装下，DOM节点其实只是作为界面展现的一种底层“汇编”而已。jQuery的选择与Witrix平台类似，都是以HTML自身结构为基础，通过js增强(enhance)DOM节点的功能，将它提升为一个具有复杂行为的扩展对象。这里的思想是非侵入式设计(non-intrusive)和优雅退化机制(graceful degradation)。语义结构在基础的HTML层面是完整的，js的作用是增强了交互行为，控制了展现形式。
     如果每次我们都通过$('#my')的方式来访问相应的包装对象，那么一些需要长期保持的状态变量保存在什么地方呢？jQuery提供了一个统一的全局数据管理机制。

这一机制自然融合了对HTML5的data属性的处理

 通过 $('#my').data('myAttr')将可以读取到HTML中设置的数据。
 
 第一次访问data时，jQuery将为DOM节点分配一个唯一的uuid, 然后设置在DOM节点的一个特定的expando属性上, jQuery保证这个uuid在本页面中不重复。

 以上代码可以同时处理DOM节点和纯js对象的情况。如果是js对象，则data直接放置在js对象自身中，而如果是DOM节点，则通过cache统一管理。
 因为所有的数据都是通过data机制统一管理的，特别是包括所有事件监听函数(data.events)，因此jQuery可以安全的实现资源管理。在clone节点的时候，可以自动clone其相关的事件监听函数。而当DOM节点的内容被替换或者DOM节点被销毁的时候，jQuery也可以自动解除事件监听函数, 并安全的释放相关的js数据。
 
7. event：统一事件模型 
  "事件沿着对象树传播"这一图景是面向对象界面编程模型的精髓所在。对象的复合构成对界面结构的一个稳定的描述，事件不断在对象树的某个节点发生，并通过冒泡机制向上传播。对象树很自然的成为一个控制结构，我们可以在父节点上监听所有子节点上的事件，而不用明确与每一个子节点建立关联。
  jQuery除了为不同浏览器的事件模型建立了统一抽象之外,主要做了如下增强:
  A. 增加了自定制事件(custom)机制. 事件的传播机制与事件内容本身原则上是无关的, 因此自定制事件完全可以和浏览器内置事件通过同一条处理路径, 采用同样的监听方式. 使用自定制事件可以增强代码的内聚性, 减少代码耦合. 例如如果没有自定制事件, 关联代码往往需要直接操作相关的对象

而如果使用自定制事件,则表达的语义更加内敛明确,

  B. 增加了对动态创建节点的事件监听. bind函数只能将监听函数注册到已经存在的DOM节点上. 例如

  如果调用bind之后,新建了另一个li节点,则该节点的click事件不会被监听. 
  jQuery的delegate机制可以将监听函数注册到父节点上, 子节点上触发的事件会根据selector被自动派发到相应的handlerFn上. 这样一来现在注册就可以监听未来创建的节点.

  最近jQuery1.7中统一了bind, live和delegate机制, 天下一统, 只有on/off.

    
8. 动画队列：全局时钟协调 
  抛开jQuery的实现不谈, 先考虑一下如果我们要实现界面上的动画效果, 到底需要做些什么? 比如我们希望将一个div的宽度在1秒钟之内从100px增加到200px. 很容易想见, 在一段时间内我们需要不时的去调整一下div的宽度, [同时]我们还需要执行其他代码. 与一般的函数调用不同的是, 发出动画指令之后, 我们不能期待立刻得到想要的结果, 而且我们不能原地等待结果的到来. 动画的复杂性就在于:一次性表达之后要在一段时间内执行,而且有多条逻辑上的执行路径要同时展开, 如何协调? 
  伟大的艾萨克.牛顿爵士在《自然哲学的数学原理》中写道:"绝对的、真正的和数学的时间自身在流逝着". 所有的事件可以在时间轴上对齐, 这就是它们内在的协调性. 因此为了从步骤A1执行到A5, 同时将步骤B1执行到B5, 我们只需要在t1时刻执行[A1, B1], 在t2时刻执行[A2,B2], 依此类推.

  具体的一种实现形式可以是 
  A. 对每个动画, 将其分装为一个Animation对象, 内部分成多个步骤.

  C. 在全局时钟的每一个触发时刻, 将每个注册的执行序列推进一步, 如果已经结束, 则从全局管理器中删除.

  解决了原理问题,再来看看表达问题, 怎样设计接口函数才能够以最紧凑形式表达我们的意图? 我们经常需要面临的实际问题:
  A. 有多个元素要执行类似的动画
  B. 每个元素有多个属性要同时变化
  C. 执行完一个动画之后开始另一个动画
jQuery对这些问题的解答可以说是榨尽了js语法表达力的最后一点剩余价值.

  A. 利用jQuery内置的selector机制自然表达对一个集合的处理.
  B. 使用Map表达多个属性变化
  C. 利用微格式表达领域特定的差量概念. '+=200px'表示在现有值的基础上增加200px
  D. 利用函数调用的顺序自动定义animation执行的顺序: 在后面追加到执行队列中的动画自然要等前面的动画完全执行完毕之后再启动.
   
  jQuery动画队列的实现细节大概如下所示,
   A. animate函数实际是调用queue(function(){执行结束时需要调用dequeue,否则不会驱动下一个方法})
      queue函数执行时, 如果是fx队列, 并且当前没有正在运行动画(如果连续调用两次animate,第二次的执行函数将在队列中等待),则会自动触发dequeue操作, 驱动队列运行.
      如果是fx队列, dequeue的时候会自动在队列顶端加入"inprogress"字符串,表示将要执行的是动画.
   B. 针对每一个属性，创建一个jQuery.fx对象。然后调用fx.custom函数(相当于start)来启动动画。
   C. custom函数中将fx.step函数注册到全局的timerFuncs中，然后试图启动一个全局的timer.
       timerId = setInterval( fx.tick, fx.interval );
   D. 静态的tick函数中将依次调用各个fx的step函数。step函数中通过easing计算属性的当前值，然后调用fx的update来更新属性。
   E. fx的step函数中判断如果所有属性变化都已完成,则调用dequeue来驱动下一个方法。

  很有意思的是, jQuery的实现代码中明显有很多是接力触发代码: 如果需要执行下一个动画就取出执行, 如果需要启动timer就启动timer等. 这是因为js程序是单线程的,真正的执行路径只有一条,为了保证执行线索不中断, 函数们不得不互相帮助一下. 可以想见, 如果程序内部具有多个执行引擎, 甚至无限多的执行引擎, 那么程序的面貌就会发生本质性的改变. 而在这种情形下, 递归相对于循环而言会成为更自然的描述. 
  
9. promise模式：因果关系的识别 
  现实中,总有那么多时间线在独立的演化着, 人与物在时空中交错,却没有发生因果. 软件中, 函数们在源代码中排着队, 难免会产生一些疑问, 凭什么排在前面的要先执行? 难道没有它就没有我? 让全宇宙喊着1,2,3齐步前进, 从上帝的角度看,大概是管理难度过大了, 于是便有了相对论. 如果相互之间没有交换信息, 没有产生相互依赖, 那么在某个坐标系中顺序发生的事件, 在另外一个坐标系中看来, 就可能是颠倒顺序的. 程序员依葫芦画瓢, 便发明了promise模式. 
  promise与future模式基本上是一回事,我们先来看一下java中熟悉的future模式.

  发出函数调用仅仅意味着一件事情发生过, 并不必然意味着调用者需要了解事情最终的结果. 函数立刻返回的只是一个将在未来兑现的承诺(Future类型), 实际上也就是某种句柄. 句柄被传来传去, 中间转手的代码对实际结果是什么,是否已经返回漠不关心. 直到一段代码需要依赖调用返回的结果, 因此它打开future, 查看了一下. 如果实际结果已经返回, 则future.get()立刻返回实际结果, 否则将会阻塞当前的执行路径, 直到结果返回为止. 此后再调用future.get()总是立刻返回, 因为因果关系已经被建立, [结果返回]这一事件必然在此之前发生, 不会再发生变化. 
  future模式一般是外部对象主动查看future的返回值, 而promise模式则是由外部对象在promise上注册回调函数.

  jQuery引入Deferred结构, 根据promise模式对ajax, queue, document.ready等进行了重构, 统一了异步执行机制. then(onDone, onFail)将向promise中追加回调函数, 如果调用成功完成(resolve), 则回调函数onDone将被执行, 而如果调用失败(reject), 则onFail将被执行. when可以等待在多个promise对象上. promise巧妙的地方是异步执行已经开始之后甚至已经结束之后,仍然可以注册回调函数
  someObj.done(callback).sendRequest() vs. someObj.sendRequest().done(callback)
 callback函数在发出异步调用之前注册或者在发出异步调用之后注册是完全等价的, 这揭示出程序表达永远不是完全精确的, 总存在着内在的变化维度. 如果能有效利用这一内在的可变性, 则可以极大提升并发程序的性能. 
   promise模式的具体实现很简单. jQuery._Deferred定义了一个函数队列，它的作用有以下几点：
   A. 保存回调函数。
   B. 在resolve或者reject的时刻把保存着的函数全部执行掉。
   C. 已经执行之后, 再增加的函数会被立刻执行。
  
   一些专门面向分布式计算或者并行计算的语言会在语言级别内置promise模式, 比如E语言.

  在E语言中, <-是eventually运算符, 表示最终会执行, 但不一定是现在. 而普通的car.moveTo(2,3)表示立刻执行得到结果. 编译器负责识别所有的promise依赖, 并自动实现调度. 
  
10. extend: 继承不是必须的 
  js是基于原型的语言, 并没有内置的继承机制, 这一直让很多深受传统面向对象教育的同学们耿耿于怀. 但继承一定是必须的吗? 它到底能够给我们带来什么? 最纯朴的回答是: 代码重用. 那么, 我们首先来分析一下继承作为代码重用手段的潜力. 
  曾经有个概念叫做"多重继承", 它是继承概念的超级赛亚人版, 很遗憾后来被诊断为存在着先天缺陷, 以致于出现了一种对于继承概念的解读: 继承就是"is a"关系, 一个派生对象"is a"很多基类, 必然会出现精神分裂, 所以多重继承是不好的.

 如果D类从A,B两个基类继承, 而A和B类中都实现了同一个函数f, 那么D类中的f到底是A中的f还是B中的f, 抑或是A中的f+B中的f呢? 这一困境的出现实际上源于D的基类A和B是并列关系, 它们满足交换律和结合律, 毕竟,在概念层面上我们可能难以认可两个任意概念之间会出现从属关系. 但如果我们放松一些概念层面的要求, 更多的从操作层面考虑一下代码重用问题, 可以简单的认为B在A的基础上进行操作, 那么就可以得到一个线性化的结果. 也就是说, 放弃A和B之间的交换律只保留结合律, extends A, B 与 extends B,A 会是两个不同的结果, 不再存在诠释上的二义性. scala语言中的所谓trait(特性)机制实际上采用的就是这一策略. 
  面向对象技术发明很久之后, 出现了所谓的面向方面编程(AOP), 它与OOP不同, 是代码结构空间中的定位与修改技术. AOP的眼中只有类与方法, 不知道什么叫做意义. AOP也提供了一种类似多重继承的代码重用手段, 那就是mixin. 对象被看作是可以被打开,然后任意修改的Map, 一组成员变量与方法就被直接注射到对象体内, 直接改变了它的行为. 
  prototype.js库引入了extend函数,

  就是Map之间的一个覆盖运算, 但很管用, 在jQuery库中也得到了延用. 这个操作类似于mixin, 在jQuery中是代码重用的主要技术手段---没有继承也没什么大不了的. 

11. 名称映射: 一切都是数据 
  代码好不好, 循环判断必须少. 循环和判断语句是程序的基本组成部分, 但是优良的代码库中却往往找不到它们的踪影, 因为这些语句的交织会模糊系统的逻辑主线, 使我们的思想迷失在疲于奔命的代码追踪中. jQuery本身通过each, extend等函数已经极大减少了对循环语句的需求, 对于判断语句, 则主要是通过映射表来处理. 例如, jQuery的val()函数需要针对不同标签进行不同的处理, 因此定义一个以tagName为key的函数映射表

这样在程序中就不需要到处写

可以统一处理

  映射表将函数作为普通数据来管理, 在动态语言中有着广泛的应用. 特别是, 对象本身就是函数和变量的容器, 可以被看作是映射表. jQuery中大量使用的一个技巧就是利用名称映射来动态生成代码, 形成一种类似模板的机制. 例如为了实现myWidth和myHeight两个非常类似的函数, 我们不需要

而可以选择动态生成

12. 插件机制：其实我很简单   
  jQuery所谓的插件其实就是$.fn上增加的函数, 那这个fn是什么东西?

  显然, $.fn其实就是jQuery.prototype的简写. 
  
  无状态的插件仅仅就是一个函数, 非常简单.

 对于比较复杂的插件开发, jQuery UI提供了一个widget工厂机制,

 调用 $('#dlg').dialog(options)时, 实际执行的代码基本如下所示:

 可以看出, 第一次调用$('#dlg').dialog()函数时会创建窗口对象实例,并保存在data中, 此时会调用_create()和_init()函数, 而如果不是第一次调用, 则是在已经存在的对象实例上调用_init()方法. 多次调用$('#dlg').dialog()并不会创建多个实例. 

13. browser sniffer vs. feature detection 
  浏览器嗅探(browser sniffer)曾经是很流行的技术, 比如早期的jQuery中

  在具体代码中可以针对不同的浏览器作出不同的处理

  if($.browser.msie) {
      // do something
  } else if($.browser.opera) {
      // ...
  }

  但是随着浏览器市场的竞争升级, 竞争对手之间的互相模仿和伪装导致userAgent一片混乱, 加上Chrome的诞生, Safari的崛起, IE也开始加速向标准靠拢, sniffer已经起不到积极的作用. 特性检测(feature detection)作为更细粒度, 更具体的检测手段, 逐渐成为处理浏览器兼容性的主流方式.

    只基于实际看见的,而不是曾经知道的, 这样更容易做到兼容未来. 

14. Prototype vs. jQuery 
  prototype.js是一个立意高远的库, 它的目标是提供一种新的使用体验，参照Ruby从语言级别对javascript进行改造，并最终真的极大改变了js的面貌。$, extends, each, bind...这些耳熟能详的概念都是prototype.js引入到js领域的. 它肆无忌惮的在window全局名字空间中增加各种概念, 大有谁先占坑谁有理, 舍我其谁的气势. 而jQuery则扣扣索索, 抱着比较实用化的理念, 目标仅仅是write less, do more而已.  
  不过等待激进的理想主义者的命运往往都是壮志未酬身先死. 当prototype.js标志性的bind函数等被吸收到ECMAScript标准中时, 便注定了它的没落. 到处修改原生对象的prototype, 这是prototype.js的独门秘技, 也是它的死穴. 特别是当它试图模仿jQuery, 通过Element.extend(element)返回增强对象的时候, 算是彻底被jQuery给带到沟里去了. prototype.js与jQuery不同, 它总是直接修改原生对象的prototype, 而浏览器却是充满bug, 谎言, 历史包袱并夹杂着商业阴谋的领域, 在原生对象层面解决问题注定是一场悲剧. 性能问题, 名字冲突, 兼容性问题等等都是一个帮助库的能力所无法解决的. Prototype.js的2.0版本据说要做大的变革, 不知是要与历史决裂, 放弃兼容性, 还是继续挣扎, 在夹缝中求生.