我应该从 MooTools 转换为 jQuery 吗? [关闭]

Posted

技术标签:

【中文标题】我应该从 MooTools 转换为 jQuery 吗? [关闭]【英文标题】:Should I convert from MooTools to jQuery? [closed] 【发布时间】:2010-09-15 05:05:44 【问题描述】:

我有一个相当大的代码库,它依赖于 MooTools v1.11,并且即将转换到 1.2 版。由于这是一个相当大的改革,我玩弄了转换为 jQuery 的想法。

谁有关于是更新到 jQuery 还是继续使用 MooTools 的建议?

我主要使用 MooTools for Ajax、拖放和一些小效果。

【问题讨论】:

更新 - 我们没有转换,仍然使用 MooTools。 【参考方案1】:

如果它没有损坏。不要修复它。

jQuery 可能有 X 或 Y,但如果一切都依赖于 MooTools,你可能需要做很多工作才能从 MooTools 转换。

如果您在整个网站中广泛使用 MooTools,请保留它。但是,如果您只有 2-3 页的影响较小...更改可能是值得的。

【讨论】:

我同意,除非您对项目的下一阶段有一些需要不同库的计划,那么现在是时候去做了。执行了几次框架重构后,我知道它从来没有看起来那么容易【参考方案2】:

如果您要升级无论如何,那么可能值得研究一下。

jQuery 似乎正在成为 One True J​​avascript 库(鉴于 MS 和其他人已经决定接受它),所以如果这是您打算使用一段时间的代码,那么它可能是一个不错的选择在某个时候切换的想法(如果只是因为会有更多的地方获得帮助和插件代码,因为它很可能会继续流行一段时间,这将有助于确保代码的长期灵活性和可维护性) .因此,鉴于您无论如何都必须转换它,现在可能是最好的时机。

我认为 jQuery 成为 框架使用是一件好事。这不是我的选择(我也喜欢 MooTools),但它肯定是一段优秀的代码,并且至少与它的竞争对手的竞争力完全吻合。我很高兴看到任何形式的一致性,并且我将在某个时候将我的代码移动到 jQuery。

【讨论】:

jQuery 从来都不是 javascript 框架,也很难成为它。这是一个图书馆。并将留在图书馆。这就是为什么它既漂亮又有吸引力。 Anthony:Nokia 到目前为止,但我怀疑现在会有更多的人跟进,MS 已经将他们的旗帜钉在了 jQuery 的柱子上。 Google、Mozilla 和许多其他人都使用 jQuery。微软和诺基亚也将其与他们的工具捆绑在一起。 Google 在哪一部分使用了 jQuery? @Alon。如果你使用 php,ezComponents = 库,CakePHP = 框架【参考方案3】:

为什么要切换?我已经将代码库从 1.11 转换为 1.2,它非常快速和简单(而且我将它用于多个效果)。

jQuery 可能会被 MS 采用,根据一个网站的说法,它在 IE 中表现更好 - 但这不是关于它在 IE 上的表现如何,而是关于它在你的网站上的表现如何(IE 是你网站上的主要参与者?)。

你知道 jQuery 吗?如果您不这样做,那么您必须从头开始重写代码,并且您将完全重写您的代码。

或者你只是想找个理由告诉你的经理“我们应该在 jQuery 中做这件事”,因为你想学习它?

至于“唯一真正的框架”——这是一个荒谬的说法,只有用户才能提出,而不是开发人员。

【讨论】:

+1 关于 MS 采用它的观点,这是另一个让我尽量避免使用 jQuery 的观点。【参考方案4】:

从 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 系统来帮助你。

特别是对于大型代码库,保持代码井井有条非常重要。

我当然有偏见。

【讨论】:

【参考方案5】:

有一个关于它的网站描述了哲学上的差异jqueryvsmootools.com

我认为这就是最终的结果。以功能性 DOM 为中心的方法或面向对象的 JavaScript 方法。

【讨论】:

【参考方案6】:

正如其他人所指出的,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 个活动链接,这是我的第一个答案]

【讨论】:

【参考方案7】:

这取决于您对 jQuery 的了解程度以及您的截止日期。如果您了解这一点,它确实需要更少的代码行数,这意味着您的客户的带宽更少。

另外,如果你看一下this site,你会发现在领先的浏览器 IE 中,jQuery 的性能比 Mootools 更好。

话虽如此,如果在 Mootools v1.11 中一切正常,你为什么要更新脚本呢?就像之前的海报说的那样,如果它没有被打破......

如果它在 Mootools v1.11 中不能正常工作,你怎么知道它在 Mootools v1.2 甚至 jQuery 中也能正常工作?投入大量的开发时间并且要么有一些相同的错误,要么因为您使用的框架而引入新的错误,这将是一种耻辱。

【讨论】:

【参考方案8】:

在这一点上,Slickspeed 变得完全不重要了,无论如何选择器都太快了。另外,您知道,Mootools 开发团队的成员 Herald Kirschner 的 Sly 刚刚发布了 Sly,这是一个击败 Sizzle 的选择器引擎。关于动画的东西是不选择由其中一张海报留下的 mootools 的决定性因素基本上是倒退,Mootools 多年来一直是动画之王。无论您选择什么,它都会起作用。 Mootools 有一种更经典的感觉,我认为这让我有条不紊,jQuery 更多地基于函数并且不会过多地冒险进入类。一个增加原生类型,另一个不增加,这是一种不同的策略,仅此而已。

丹尼尔

【讨论】:

【参考方案9】:

我对 Mootools 很满意。我曾多次尝试尝试 jQuery,因为这些天越来越多的人在使用它,但不知何故,我仍然没有像 Mootools 那样获得好的 OO 功能。我不太喜欢 jQuery 的另一件事是通过添加 hashkey(#) 来使用美元函数获取 id。如果您想使用框架创建 html id,这可能会出现问题。如果我是你,只需升级到最新版本的 Mootools。 Mootools 根本不是一个糟糕的库。

【讨论】:

【参考方案10】:

在您的问题中,您提到您将 MooTools 用于“Ajax、拖放和一些次要效果”。虽然 Mootools 可以做到这一点,但(我可能会因为这样说而受到抨击)在我看来,你并没有真正出于正确的原因使用 Mootools。我们在应用程序中使用 Mootools,实际上我们不能考虑用 JQuery 来代替它。如果目标是编写您组织中的其他应用程序可以利用的面向对象的、长期可维护的代码,那么 Mootools 就胜出。

而且仅仅选择器速度是一个错误的判断标准(尽管我相信 Mootools 现在就在那里)。我们代码中的大多数地方已经引用了我们想要更改的元素。一旦你拥有了元素,大部分时间都花在实际操作 DOM 上,并且在我们的内部测试(将尝试发布它们)中,在我们执行的通常类型的操作中,Mootools 比 JQuery 快得多。我们的应用程序依赖于之前构建的 Mootools 控件(由我们或其他人构建)来使用来自 Web 服务的数据创建应用程序屏幕。

【讨论】:

【参考方案11】:

评估您是否有程序员的时间进行大修。 这样做意味着您将从头开始重写代码。这再次意味着您将不得不经历功能、审查和测试、修复错误等循环。也就是说,对 JavaScript 不太熟练的程序员所造成的最重要问题之一是大多数代码访问 DOM 元素往往会造成内存泄漏(这是大多数 Web 开发人员经常遇到的情况)。 jQuery 本质上为减轻这种情况做了很多工作。或者更确切地说,jQuery 从 JavaScript 中移除了 JavaScript。 第二。迁移到 jquery 的更令人信服的原因之一是您的 JavaScript 代码量将显着减少。这对于客户端代码密集型页面是有意义的。 jquery 的简洁性也让您可以轻松地查看代码。 我工作的公司 (support.com) 拥有大量的 Mootools 代码。在 2008 年初(经过几个小时的激烈辩论——我反对迁移到 jQuery),我们开始分阶段迁移到 jQuery。到目前为止,我没有后悔过。

【讨论】:

【参考方案12】:

这个说法很无聊,Mootools 是 O-O,所以形成适当 O-O 背景的人比 PHP4 或 HTML 背景的人更欣赏它的智能。

【讨论】:

【参考方案13】:

我可以为这种迁移给出的唯一令人信服的理由是,如果进行切换会减少您必须维护的代码量,和/或使事情变得更简单。这种转换通常涉及大量工作,因此您希望能够在所有工作完成后返回并说“是的,这是值得的。”

【讨论】:

【参考方案14】:

您应该根据您的应用程序的目的进行此选择。

jQuery 对于动画来说非常酷,但是我觉得 Mootools 更复杂,所以如果重要的是应用程序而不是动画坚持 Mootools

速度也是这方面的一个主题。截至今天,Mootools 的性能稍慢,但我宁愿在 Mootools 1.3 发布之前不关注它。

在http://slicktest.perrohunter.com查看最新框架的性能

【讨论】:

【参考方案15】:

JQuery 是一个较小的代码库,具有更广泛的支持。如果它满足您的需求,它可能是一个很好的开关。我想说的是,您需要权衡的是迁移工作和学习曲线是否值得付出努力,而不是更广泛的功能集、更小的代码大小和流行度以及对 JQuery 的支持。

如果 MooTools 版本之间的变化真的那么大,那么迁移可能是合理的。

【讨论】:

【参考方案16】:

jqueryvsmootools 网站上提到的文章说得很好:

如果 jQuery 让 DOM 成为你的游乐场,那么 MooTools 的目标就是让 JavaScript 成为你的游乐场

所以,再加上这里的答案“如果它没有坏,就不要修复它”,我想说的是解决您的需求而不是公众舆论。

鉴于您的网站已经在 Mootools 中,您需要评估 jQuery 是否提供了 MooTools 不提供的任何您需要的东西;以及转换的麻烦是否小于编写扩展的麻烦。

似乎 jQuery 能够让您快速使用 DOM,但所有额外花哨的东西和其他工作领域(如 Dates)都需要插件。

这也帮助我回答了我自己的问题!

有些区域不重叠,很可惜。 GUI 很容易在 jQuery 中组合在一起,带有可爱的小部件和动画。我发现 MooTools 的功能集太少,或者对于一般网络使用来说太重了。

【讨论】:

以上是关于我应该从 MooTools 转换为 jQuery 吗? [关闭]的主要内容,如果未能解决你的问题,请参考以下文章

是否有与 MooTools 的 Element() 构造函数等效的 jQuery?

普通的 JavaScript 是不是比使用 jQuery 或 MooTools 等框架更好? [关闭]

如何创建“Mootools主页”™ 使用jQuery的灵感导航效果

几种流行的AJAX框架对比:Jquery,Mootools,Dojo,ExtJs,Dwr

使用 JQuery 处理来自帖子的数据的正确方法

OO JQuery 和类