我应该从MooTools转换为jQuery吗?

时间:2008-10-03 22:35:40

标签: javascript jquery mootools

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

任何人都有关于是否更新到jQuery或只是坚持使用MooTools的建议吗?

我主要使用MooTools进行Ajax,拖放和一些小的效果。

16 个答案:

答案 0 :(得分:28)

如果它没有坏掉。不要修理它。

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

如果您在整个网站中广泛使用MooTools,请将其保留下来。但是,如果您只有2-3页具有轻微影响......这种变化可能是值得的。

答案 1 :(得分:17)

如果你正在升级 ,那么可能值得研究。

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

我认为jQuery成为 框架是一件好事。这不是我的选择(我也喜欢MooTools),但它肯定是一个很好的代码,绝对符合目的,至少具有竞争的能力。我很高兴看到任何一致性,我将在某些时候将代码移动到jQuery。

答案 2 :(得分:13)

为什么要进行切换?我已经将代码库从1.11转换为1.2,并且它非常快速和简单(而且我使用的不仅仅是一些效果)。

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

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

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

就“一个真正的框架”而言 - 这是一个只有用户做出的荒谬主张,而不是开发者。

答案 3 :(得分:8)

从MooTools 1.1.1到1.2.1的转换并不是什么大不了的事。 http://github.com/mootools/mootools-core/wikis/conversion-from-1-11-to-1-2

甚至还有一个兼容层,可以在1.2.x中实现MooTools 1.1.1代码功能。你可能不得不在这里和那里手动修复一些东西,但它相对较小。

切换到jQuery,或YUI或DOJO,或其他任何东西都需要完全抛弃你拥有的所有代码并说明。我的客户不会允许这种浪费。

此外,如果您习惯使用正确的MooTools类进行编码,那么jQuery可能会对您的系统造成巨大冲击。并不是jQuery强迫你编写不可读和不可维护的代码,用任何语言编写非常易读和可维护的代码当然是可能的。但是jQuery没有内置的Class系统来帮助你。

特别是对于大型代码库,保持代码组织良好非常重要。

我当然很偏颇。

答案 4 :(得分:4)

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

我认为这最终归结为什么。功能性DOM中心方法或面向对象的JavaScript方法。

答案 5 :(得分:4)

正如其他人所指出的,jQuery是一个库(主要用于玩弄DOM),Mootools(1.2)是一个完整的javascript框架,允许您以面向对象的方式组织代码,从而使其易于维护

我建议您阅读本文以了解每个人的真实情况(jqueryvsmootools.com)

另外这个链接,让你知道如何从两个世界中获得最佳效果;):

http://ryanflorence.com/object-oriented-jquery-with-mootools-pigs-take-flight/

最后归结为需要的东西。我的一般建议:如果你需要抓住一些快速片段并将你的web应用程序归结为jQuery就好了;如果你要在javascript中集中你的开发,你应该尝试mootools:代码扩展,你应该做好准备。

要从Mootools 1.1升级代码,您可以使用升级帮助程序,它将帮助您通过javascript控制台识别冲突代码(mootools.net/blog/2009/12/31/mootools-1-1-upgrade i-层-β/)

[抱歉只发布1个活动链接,这是我的第一个回答]

答案 6 :(得分:3)

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

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

话虽如此,如果一切都在Mootools v1.11中运行,为什么要更新脚本呢?就像之前的海报所说的那样,如果没有破坏......

如果它在Mootools v1.11中无法正常工作,你怎么知道它可以在Mootools v1.2甚至jQuery中使用?放一堆开发时间,或者有一些相同的错误,或者因为你使用的框架而引入新的bug,这将是一种耻辱。

答案 7 :(得分:3)

此时Slickspeed变得完全不重要,无论如何选择器太快了。也正如你所知,Sly by Herald Kirschner,Mootools开发团队的成员刚刚发布了Sly,一个击败Sizzle的选择器引擎。关于动画是不选择其中一张海报所留下的mootools的决定性因素的东西基本上是屁股倒退,Mootools多年来一直是动画之王。无论你选择什么,它都会奏效。 Mootools有一种更经典的感觉,我认为让我保持井井有条,jQuery更多的是基于功能,并且不会冒险进入类。一个增加原生类型而另一个不增加,不同的策略,但就是它。

  • 丹尼尔

答案 8 :(得分:3)

我对Mootools很满意。我已经试过几次尝试jQuery,因为现在有越来越多的人在使用它,但不知怎的,我仍然没有像Mootools那样得到漂亮的OO功能。我不喜欢jQuery的另一件事是通过添加hashkey(#)来获取带有美元函数的id。如果要使用框架创建html ID,这可能会有问题。如果我是你,只需升级到最新版本的Mootools。 Mootools根本不是一个糟糕的图书馆。

答案 9 :(得分:3)

在你的问题中,你提到你正在使用MooTools进行“Ajax,拖放和一些轻微的影响”。虽然Mootools可以很好地做到这一点,(我可能会因此而受到抨击)在我看来,你并没有真正使用Mootools。我们在我们的应用程序中使用Mootools,实际上我们无法考虑用JQuery代替它。如果目标是编写面向对象的长期可维护代码,组织中的其他应用程序可以利用这些代码,Mootools将获胜。

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

答案 10 :(得分:2)

评估你是否有程序员工作时间进行过度交付     这样做意味着您将从头开始重写代码。这再次意味着你将不得不经历功能循环,审查和测试,修复错误等。这就是说,程序员对JavaScript不那么称职的一个最重要的问题是大多数代码访问DOM元素倾向于创建内存泄漏(这是大多数Web开发人员的高速公路案例)。 jQuery本质上做了很多工作来缓解这个问题。或者更确切地说,jQuery从JavaScript中删除了JavaScript     第2位。转向jquery的一个更令人信服的理由是,您的JavaScript代码权重将急剧下降。这对于客户端代码密集型页面是有意义的。 jquery的简洁性也可以让您轻松查看代码     我工作的公司(support.com)有大量的Mootools代码。在2008年初(经过激烈的辩论 - 我反对转向jQuery)之后,我们开始分阶段迁移到jQuery。直到约会,我才后悔。

答案 11 :(得分:2)

这个论点很无聊,Mootools是O-O,所以人们形成一个合适的O-O背景,比PHP4或HTML背景的人更了解它的智能。

答案 12 :(得分:1)

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

答案 13 :(得分:1)

您应该根据申请的目的做出这个选择。

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

速度也是这方面的主题。截至今天,Mootools的性能略有下降,但在Mootools 1.3发布之前我不会注意它。

http://slicktest.perrohunter.com

查看最新框架的效果

答案 14 :(得分:0)

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

如果MooTools版本之间的变化非常陡峭,那么迁移可能是合理的。

答案 15 :(得分:0)

jqueryvsmootools网站上提到的文章很好地说明了这一点:

  

如果jQuery让DOM成为你的游乐场,MooTools旨在让JavaScript成为你的游乐场

所以,再加上这里的答案“如果它没有破坏,就不要修理它”,我会说你的需求而不是公众舆论。

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

似乎jQuery能够快速允许你玩DOM,但所有额外的花哨东西和其他工作领域(比如Dates)都需要一个插件。

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

有些地方没有重叠,这很可惜。 GUI很容易放在jQuery中,有可爱的小部件和动画。我发现,MooTools的功能设置太少,或者对于一般的网络使用来说太重了。