Mootools和Jquery之间的选择问题

    Portotype虽然是强大的，和script.aculo.us结合可以做出很多完美的效果，可是它里面有太多我不想用的代码，或许这是我后面选择mootools的主要原因，我只是想选择性的打包。其实当时我也很想用一下jquery，仔细对比了一下，我还是觉得mootools更加的适合于我。有比较，才有机会去选择，我想从下面5个方面讨论一下。
可读性VS简洁
    在网上，很多人把mootools比作java，把jquery比作perl，jquery的口号是“write less,do more”，或许就是这个目标造就了它的诡异。我觉得和mootools代码比起来，我看jquery的代码更加的吃力，有时候一行代码需要看半个小时才可以搞懂它的意思，这在mootools中是不存在的。如果你本身是一个崇尚代码简洁的人，或许jquery是你的很好的选择。虽然jquery的性能也稍高一点，不过，我觉得可读性更重要，所以我觉得mootools更加适合我。
重复的制造轮子VS拿来主义
    在所有的js框架中，我始终觉得Ext框架是“拿来主义者”们最好的选择。和ext比起来，jquery UI 其实做的不怎么样，但是jquery有很多的插件。几乎你看到的网页效果，在jquery的插件库中都可以找到，为了避免重复的制造轮子，或许jquery是一个不错的选择。而我觉得重复的制造轮子会让我更加的熟悉制作的工艺，从中了解每种框架不同之处和各自的优势，所以，我没事就修改一下jquery框架中的插件，让他们用mootools的方式去运行。我之所以在大学阶段对面向对象理解不够深刻，主要是各种IDE工具让我成了IT民工。现在，我不能再做肤浅的拿来主义者，好多的代码因为性能问题，必须手写。
团队协作的成果VS天才的思维
    jquery是程序天才JOHN RESIG的作品，mootools是一个团队的作品，有时候天才的思维很难读懂，我并不是想为此而逃避不去学习，主要是我希望用一个灵感汇聚的js框架。值得肯定的是：jquery的很多代码都写的比mootools优雅一些，简洁一点，注意这里是简洁而不是简单。团队中，思想的碰撞要多一些，产品的尝起来也就更清淡一些。我希望循序渐进的去理解js，所以我对自己不能用猛药，mootools像一碗粥，而不是参汤。
项目VS个人学习
    其实在我们产品部的项目中用的是ExtJs，这个框架帮你做了所有的事情，你基本只管调用就可以了。后来看一下，或许使用jquery UI会好一点，主要是好多代码自己都可以去尝试写一下。如果你在做项目，强烈建议使用jquery，因为很多他的插件可以帮你按照项目的工期完成任务，当然这是第一步，后面或许因为性能问题，你需要修改很多地方的代码。如果是产品部慢慢的在一个框架上有积累的话，或许不会有这样的问题存在，我是建议一个产品部能够持续的学习一个框架，无论是哪一个，精通的过程是痛苦的，可是如果不精通，整个产品都是痛苦的。
完成任务VS希望成为高手
    前面已经说过：如果想更快的完成任务，你需要选择jquery，如果想痛苦的积累，选择mootools或许会更好。才开始使用mootools1.2的时候，我几乎崩溃，因为我写的1.1的代码都不能用了，后来没事看了一下1.2的源代码，无论是在功能上还是在性能上，这样的改动是有必要的。同时，也赞扬一下mootools团队的勇气，和老版本的不兼容真的会让很多人抓狂。一点点的积累，一点点的领悟JavaScript，mootools是一个不错的选择。

以上内容其实很火星，因为去年我就选择mootools了，最近突然看到一个帖子来讨论这两个框架的时候，我有点遗憾没能在当时记录一下自己的想法，赶快补写一篇。不知道大家的想法如何？

感同身受

看得我也想读读mootools了，我想问下，你说的“选择性打包”是什么意思？是指可以自己删改mootools的某个部分？

基本上，我选择mootools而非jQuery也是出于差不多的考虑
基于众所周知的原因，javascript是一门很特殊的语言，很长一段时间内它甚至没有被作为语言来看待
我有个朋友写了半年多的js之后，跟我说过，无论是多有经验的程序员，第一次写复杂的js程序总会掉到某个坑里。“性能”是最容易掉进去的坑之一，还有一个大坑就是“兼容性”。
如果仅仅是完成onmouseover、onmouseout之类的小把戏，随便什么库都可以很方便的完成，而且基本不会带来什么问题。
但是如果你正在拿js写复杂一些的逻辑，浏览器兼容性、性能问题就会时常的成为你需要花费精力去debug的项目。
如上所说，当解决了很多这种问题之后，我渐渐的倾向于自己写代码来控制一切，或者说尽量让自己的代码控制得更多，这也是为什么我不会去选择Ext、dojo这种重型的库

我曾经用过一段时间的extjs，的确是天才作品，但是仍然会有刺痛我的地方，说两个还记得的问题
日期控件在firefox3里面布局出错
两个ComboBox之间连动时，ComboBox的事件没有被正确的触发，依稀记得是data store的事件的毛病

那时用的extjs1.x，现在肯定没这个问题了，我只是想说明，即使extjs这样的作品，在实际使用时仍然会需要你去hack它的代码，如果你用得足够多。有时候hack代码的工作量差不多足够你自己写一个了

从另外一个角度来说，你选择这种重型库的初衷就是节约你的时间，但是搞不好某个魔鬼细节反而让你多花了不少时间，不是搞FUD，只是个人经验而已，见仁见智。

继续jQuery和mootools的比较

jQuery的代码我没细读过，不好乱说，但是它的良好封装反而是我不选择它的原因，关于这个问题已经很多人说过了，我总结就是"write less, think less"

再说个实质点的问题，比如我用mootools创建了一个dialog widget

var Dialog = new Class({
    Implements: Events,
    initialize: function() {
    },
    show: function() {
        // ....
        this.fireEvent('show', this);
    }
});

var dialog = new Dialog();
dialog.addEvent('show', function() {
    // ....
});

mootools可以很方便的自定义event
jQuery对浏览器的event进行了非常好的封装，但是貌似不支持自定义event，这样我的widget之间就无法通过自定义事件来相互驱动

我不是jQuery痛恨者，用过prototype、dojo、extjs、mootools，并且或多或少的读了它们的代码之后，发觉mootools更符合我的开发要求

就例子论例子，jQuery还是可以自定义event的，而且也不麻烦：

$("something").bind("yourEventName", function(event, msg) {
  alert(msg);
})

$("something").trigger("yourEventName", ["msg"]);

当初我也经历过Mootools和jQuery之间选择的问题，Mootools的源码让我在阅读时有种非常舒畅的感觉，但不是每个人都需要去阅读它，而且个人认为从使用者角度来说，jQuery的简洁和淡化类的理念更容易保证代码质量。

当你下载mootools的时候，你可以定制框架中自己想要的一些代码，不用的代码不选择就可以了。你可以到mootools.net上去尝试一下就好了。

非常感谢，正好我决定要开始读mootools的源代码。

mootools代码还没看过，不过jquery没什么诡异的代码吧，整个代码可读性还好，不太影响可读性的前提下省一些容量没什么不好的。

jquery的代码已经超出我的智商，想换到mootools，但似乎mootools更新太慢了，活跃度太低了

@keshin:
谢谢你的例子，我对jQuery的确不是非常熟悉，所以也只敢说“貌似不支持自定义event”
还好我没有很肯定的乱说，不然就贻笑大方了，哈哈