我有一个相当大的代码库，它依赖于 MooTools v1.11，并且即将转换到 1.2 版。由于这是一个相当大的改革，我玩弄了转换为 jQuery 的想法。
谁有关于是更新到 jQuery 还是继续使用 MooTools 的建议？
我主要使用 MooTools for Ajax、拖放和一些小效果。
【问题讨论】：
标签： javascript jquery mootools
如果它没有损坏。不要修复它。
jQuery 可能有 X 或 Y，但如果一切都依赖于 MooTools，你可能需要做很多工作才能从 MooTools 转换。
如果您在整个网站中广泛使用 MooTools，请保留它。但是，如果您只有 2-3 页的影响较小...更改可能是值得的。
【讨论】：
如果您要升级无论如何，那么可能值得研究一下。
jQuery 似乎正在成为 One True Javascript 库（鉴于 MS 和其他人已经决定接受它），所以如果这是您打算使用一段时间的代码，那么它可能是一个不错的选择在某个时候切换的想法（如果只是因为会有更多的地方获得帮助和插件代码，因为它很可能会继续流行一段时间，这将有助于确保代码的长期灵活性和可维护性） .因此，鉴于您无论如何都必须转换它，现在可能是最好的时机。
我认为 jQuery 成为 框架使用是一件好事。这不是我的选择（我也喜欢 MooTools），但它肯定是一段优秀的代码，并且至少与它的竞争对手的竞争力完全吻合。我很高兴看到任何形式的一致性，并且我将在某个时候将我的代码移动到 jQuery。
【讨论】：
为什么要切换？我已经将代码库从 1.11 转换为 1.2，它非常快速和简单（而且我将它用于多个效果）。
jQuery 可能会被 MS 采用，根据一个网站的说法，它在 IE 中表现更好 - 但这不是关于它在 IE 上的表现如何，而是关于它在你的网站上的表现如何（IE 是你网站上的主要参与者?)。
你知道 jQuery 吗？如果您不这样做，那么您必须从头开始重写代码，并且您将完全重写您的代码。
或者你只是想找个理由告诉你的经理“我们应该在 jQuery 中做这件事”，因为你想学习它？
至于“唯一真正的框架”——这是一个荒谬的说法，只有用户才能提出，而不是开发人员。
【讨论】：
从 MooTools 1.1.1 切换到 1.2.1 并不是什么大问题。 http://github.com/mootools/mootools-core/wikis/conversion-from-1-11-to-1-2
甚至还有一个兼容层使 MooTools 1.1.1 代码在 1.2.x 中起作用。您可能需要在这里和那里手动修复一些问题，但这相对较小。
切换到 jQuery、YUI 或 DOJO，或其他任何东西都需要完全抛弃所有代码并重新声明。我的任何客户都不会允许这种浪费。
此外，如果您习惯于使用适当的 MooTools 类进行编码，那么 jQuery 可能会给您的系统带来巨大的冲击。并不是说 jQuery 强迫你编写不可读和不可维护的代码，当然可以用任何语言编写非常可读和可维护的代码。但是 jQuery 没有内置的 Class 系统来帮助你。
特别是对于大型代码库，保持代码井井有条非常重要。
我当然有偏见。
【讨论】：
有一个关于它的网站描述了哲学上的差异jqueryvsmootools.com
我认为这就是最终的结果。以功能性 DOM 为中心的方法或面向对象的 JavaScript 方法。
【讨论】：
正如其他人所指出的，jQuery 是一个库（主要用于玩弄 DOM），Mootools (1.2) 是一个成熟的 javascript 框架，它允许您以面向对象的方式组织代码，从而使其易于维护.
我建议您阅读本文以真正了解每一个的真正含义 (jqueryvsmootools.com)
还有这个其他链接，所以你知道如何从两个世界中获得最好的;）：
http://ryanflorence.com/object-oriented-jquery-with-mootools-pigs-take-flight/
最终归结为您需要什么。我的一般建议：如果你需要一些快速的 sn-ps 并幻想你的 web 应用程序，单独使用 jQuery 是好的；如果您打算以 javascript 为中心进行开发，那么您真的应该尝试 mootools：代码会扩展，您最好做好准备。
要从 Mootools 1.1 升级您的代码，您可以使用升级助手，它将帮助您通过 javascript 控制台识别冲突代码 (mootools.net/blog/2009/12/31/mootools-1-1-upgrade -layer-beta/)
[抱歉只发布了 1 个活动链接，这是我的第一个答案]
【讨论】：
这取决于您对 jQuery 的了解程度以及您的截止日期。如果您了解这一点，它确实需要更少的代码行数，这意味着您的客户的带宽更少。
另外，如果你看一下this site，你会发现在领先的浏览器 IE 中，jQuery 的性能比 Mootools 更好。
话虽如此，如果在 Mootools v1.11 中一切正常，你为什么要更新脚本呢？就像之前的海报说的那样，如果它没有被打破......
如果它在 Mootools v1.11 中不能正常工作，你怎么知道它在 Mootools v1.2 甚至 jQuery 中也能正常工作？投入大量的开发时间并且要么有一些相同的错误，要么因为您使用的框架而引入新的错误，这将是一种耻辱。
【讨论】：
在这一点上，Slickspeed 变得完全不重要了，无论如何选择器都太快了。另外，您知道，Mootools 开发团队的成员 Herald Kirschner 的 Sly 刚刚发布了 Sly，这是一个击败 Sizzle 的选择器引擎。关于动画的东西是不选择由其中一张海报留下的 mootools 的决定性因素基本上是倒退，Mootools 多年来一直是动画之王。无论您选择什么，它都会起作用。 Mootools 有一种更经典的感觉，我认为这让我有条不紊，jQuery 更多地基于函数并且不会过多地冒险进入类。一个增加原生类型，另一个不增加，这是一种不同的策略，仅此而已。
【讨论】：
我对 Mootools 很满意。我曾多次尝试尝试 jQuery，因为这些天越来越多的人在使用它，但不知何故，我仍然没有像 Mootools 那样获得好的 OO 功能。我不太喜欢 jQuery 的另一件事是通过添加 hashkey(#) 来使用美元函数获取 id。如果您想使用框架创建 html id，这可能会出现问题。如果我是你，只需升级到最新版本的 Mootools。 Mootools 根本不是一个糟糕的库。
【讨论】：
在您的问题中，您提到您将 MooTools 用于“Ajax、拖放和一些次要效果”。虽然 Mootools 可以做到这一点，但（我可能会因为这样说而受到抨击）在我看来，你并没有真正出于正确的原因使用 Mootools。我们在应用程序中使用 Mootools，实际上我们不能考虑用 JQuery 来代替它。如果目标是编写您组织中的其他应用程序可以利用的面向对象的、长期可维护的代码，那么 Mootools 就胜出。
而且仅仅选择器速度是一个错误的判断标准（尽管我相信 Mootools 现在就在那里）。我们代码中的大多数地方已经引用了我们想要更改的元素。一旦你拥有了元素，大部分时间都花在实际操作 DOM 上，并且在我们的内部测试（将尝试发布它们）中，在我们执行的通常类型的操作中，Mootools 比 JQuery 快得多。我们的应用程序依赖于之前构建的 Mootools 控件（由我们或其他人构建）来使用来自 Web 服务的数据创建应用程序屏幕。
【讨论】：
评估您是否有程序员的时间进行大修。
这样做意味着您将从头开始重写代码。这再次意味着您将不得不经历功能、审查和测试、修复错误等循环。也就是说，对 JavaScript 不太熟练的程序员所造成的最重要问题之一是大多数代码访问 DOM 元素往往会造成内存泄漏（这是大多数 Web 开发人员经常遇到的情况）。 jQuery 本质上为减轻这种情况做了很多工作。或者更确切地说，jQuery 从 JavaScript 中移除了 JavaScript。
第二。迁移到 jquery 的更令人信服的原因之一是您的 JavaScript 代码量将显着减少。这对于客户端代码密集型页面是有意义的。 jquery 的简洁性也让您可以轻松地查看代码。
我工作的公司 (support.com) 拥有大量的 Mootools 代码。在 2008 年初（经过几个小时的激烈辩论——我反对迁移到 jQuery），我们开始分阶段迁移到 jQuery。到目前为止，我没有后悔过。
【讨论】：
这个说法很无聊，Mootools 是 O-O，所以形成适当 O-O 背景的人比 PHP4 或 HTML 背景的人更欣赏它的智能。
【讨论】：
我可以为这种迁移给出的唯一令人信服的理由是，如果进行切换会减少您必须维护的代码量，和/或使事情变得更简单。这种转换通常涉及大量工作，因此您希望能够在所有工作完成后返回并说“是的，这是值得的。”
【讨论】：
您应该根据您的应用程序的目的进行此选择。
jQuery 对于动画来说非常酷，但是我觉得 Mootools 更复杂，所以如果重要的是应用程序而不是动画坚持 Mootools
速度也是这方面的一个主题。截至今天，Mootools 的性能稍慢，但我宁愿在 Mootools 1.3 发布之前不关注它。
在http://slicktest.perrohunter.com查看最新框架的性能
【讨论】：
JQuery 是一个较小的代码库，具有更广泛的支持。如果它满足您的需求，它可能是一个很好的开关。我想说的是，您需要权衡的是迁移工作和学习曲线是否值得付出努力，而不是更广泛的功能集、更小的代码大小和流行度以及对 JQuery 的支持。
如果 MooTools 版本之间的变化真的那么大，那么迁移可能是合理的。
【讨论】：
jqueryvsmootools 网站上提到的文章说得很好：
如果 jQuery 让 DOM 成为你的游乐场，那么 MooTools 的目标就是让 JavaScript 成为你的游乐场
所以，再加上这里的答案“如果它没有坏，就不要修复它”，我想说的是解决您的需求而不是公众舆论。
鉴于您的网站已经在 Mootools 中，您需要评估 jQuery 是否提供了 MooTools 不提供的任何您需要的东西；以及转换的麻烦是否小于编写扩展的麻烦。
似乎 jQuery 能够让您快速使用 DOM，但所有额外花哨的东西和其他工作领域（如 Dates）都需要插件。
这也帮助我回答了我自己的问题！
有些区域不重叠，很可惜。 GUI 很容易在 jQuery 中组合在一起，带有可爱的小部件和动画。我发现 MooTools 的功能集太少，或者对于一般网络使用来说太重了。
【讨论】：