The Ajax Experience at Boston会议中，John Resig和jQuery大放异彩。John Resig做了《JavaScript Libraries》的演讲，这引发了Ajaxian和不少Blog上关于js库的又一次讨论。Aaron Newton写了一篇长文，提出Programming to the Pattern, 指出jQuery无法很好的做到这一点，而MooTools则非常适合。Aaron的这个论点，和我目前的感觉一致。jQuery易用的同时也宠坏了用户，Everyone Is a Noob At Something, But We All Learn Eventually. 刚开始使用jQuery，会感觉非常容易同时很有成就感，成就感能进一步激发兴趣（对于js的推广普及，John Resig劳苦功高，非常值得敬佩）。但随着代码的增多和编程经验的提升，一个好的程序员会开始想resuable, flexible, refactor等概念。这时，面对用jQuery快速开发出来的一堆代码就会有点头疼了。

当然，并不是用jQuery就写不出易扩展和可复用性高的代码。对于一个熟练的经验丰富的优秀程序员来说，即便用原生的js, 也能写出味道非常好的代码。这里想讨论的问题是，MooTools的框架设计和内蕴的编程风格，可能更能引诱程序员朝着味道好的方向去编写代码，而jQuery的哲理是Write less, do more, 快速便捷的同时，可能会使得大部分初级程序员写出短小很有成就感但味道却并不怎么好的代码来。

有一个值得思考的问题是，前端开发中，js脚本或许简简单单就已经够用了？以我的经验，对于web page来说，大部分js都是针对特定页面，是一次性的，而且也没有复杂到必须用oo思想来编写的地步。按照ppk的说法，js的作用仅仅是给页面增加一层可访问性，js最终将归结到瘦应用上。如果ppk的感觉是对的，那jQuery就已经足够用了。从另一方面讲，简简单单的针对特定页面编写的js代码，可维护性上其实比可复用性高的widgets更好一些。因为一个页面出问题了，只需修改这个页面的js即可。用widgets的话，修改一个widget后，得检查所有引用这个widget的页面。随着需求的变动，一个widget还可能演化出多个版本。这些维护成本不低，可复用性和可扩展性在web page应用中，除非一开始就设计得很好，否则后期的修改会让人发疯的。可复用性等传统的好思想，碰上web page, 可能并不是那么重要。

说到这里，不得不提web app. 比如GMail等应用场景。这些应用中，ppk的说法是不妥的。对于用AJAX构建的web app来说，js是一种最基本的语言，如果不支持js, 这个app就是不可用的，不需要过多考虑没有js时的可访问性（除GMail有一个HTML基本版，Google的其它应用，在没有js时，也仅仅给了个提示罢了）。这就如电影院，没有买票你就站在门外吧，老板不会考虑另建一个免票版影院。在web app的应用中，页面的复杂性很高，js是当java来用的。这时一个好的js框架，可以让复杂代码的搭建变得容易，维护性也更好。这种应用中，感觉才是MooTools和Ext等框架的真正用武之地。而jQuery在这种应用就会有点难受。

对于MooTools, 它的代码的确很漂亮。以至于有人这么评论：“用mootools的code, 写jquery的api, 开发ext那么多widgets”. 这个评论很俏皮但也很地道。MooTools的代码风格很好，但最近读它的源代码，发现MooTools对原生js做了非常多的扩展（官方的解释是这样能提高性能），走的是Prototype的路子，这种侵入性让我感觉很不舒服。MooTools的字面意义就是 My OO Tools, 里面的OO思想的确很彻底，这也是MooTools代码漂亮的一个主要因素。但MooTools目前的社区有点封闭，以后会不会流行起来，现在还很难说。

各个框架的关注点不同，适用的场景也不同。也许本就不存在竞争，争论孰优孰劣实在有点无聊。在《大胆预测下几个JavaScript框架的走势》一文中，我可能伤了部分jQuery fans的感情，在此表示歉意，以后我不会再参与这种话题的讨论。凭借John Resig的能力（John Resig这次被人取了个外号叫Mr. Rockstar JS），我相信jQuery近两三年是不会没落的。在web page的应用中，jQuery会继续红火。期待jQuery UI的质量能上一个档次，等到那时，再来和YUI、Ext比较，可能会更有意思一些。