为什么jQuery如此广泛地被采用而不是其他Javascript框架?

时间:2009-06-13 05:56:34

标签: javascript jquery frameworks mootools

我管理一群程序员。我非常重视员工的意见,但最近我们对在Web项目中使用哪个框架存在分歧。

我个人赞成 MooTools ,但我的某些团队似乎希望迁移到jQuery,因为它被广泛采用。这本身不足以让我允许迁移。

我使用了 jQuery MooTools This particular essay倾向于反映我对这两个框架的看法。 jQuery 非常适合DOM操作,但似乎仅限于帮助您实现这一目标。

功能明智, jQuery MooTools 都可以轻松 DOM选择和操作

// jQuery
$('#someContainer div[class~=dialog]')
    .css('border', '2px solid red')
    .addClass('critical');

// MooTools
$('#someContainer div[class~=dialog]')
    .setStyle('border', '2px solid red')
    .addClass('critical');

jQuery MooTools 都可以轻松 AJAX

// jQuery
$('#someContainer div[class~=dialog]')
     .load('/DialogContent.html');

// MooTools (Using shorthand notation, you can also use Request.HTML)
$('#someContainer div[class~=dialog]')
     .load('/DialogContent.html');

jQuery MooTools 都可以轻松实现 DOM动画

// jQuery
$('#someContainer div[class~=dialog]')
    .animate({opacity: 1}, 500);

// MooTools (Using shorthand notation, you can also use Fx.Tween).
$('#someContainer div[class~=dialog]')
    .set('tween', {duration: 500}) 
    .tween('opacity', 1);

jQuery 提供以下附加功能:

  • 大型支持者社区
  • 插件存储库
  • 与Microsoft的ASP.NET和VisualStudio集成
  • 由Microsoft,Google和其他人使用

MooTools 提供以下附加功能:

  • 面向对象的框架,带有JS的经典OOP仿真
  • 扩展原生对象
  • 本机功能支持的浏览器之间的一致性更高。
  • 更轻松的代码重用
  • 由万维网联盟,Palm等人使用。

鉴于此, MooTools 似乎 jQuery 的所有内容都做得更多(我在 {{中无法做到的一些事情) 3}} 我可以在 jQuery )但 MooTools 的学习曲线较小。

问题是,您或您的团队为什么选择 jQuery 而不是其他JavaScript框架?

注意:虽然我知道并承认 jQuery 是一个很棒的框架,但还有其他选择,我正在尝试做出决定为什么 jQuery 应该是我们的选择而不是我们现在使用的( jQuery )?

20 个答案:

答案 0 :(得分:62)

这是一个奇怪的问题......我得到的印象是......

  1. 您非常熟悉mootools并充分利用其OOP模型,使您的代码更易于管理和支持。
  2. 你意识到jQuery的目的有些不同,并且调整了DOM操作和AJAX,而mootools确实做了jQuery所做的一切,然后是一些。
  3. 听起来好像你不需要在第三方插件中使用太多,这使得jQuery的受欢迎程度和支持点不那么重要。
  4. 底线,是炒作吗? jQuery正在变成这些神奇的营销流行语之一,如'AJAX',.NET和Web 2.0 - 这对他们来说很棒,但为什么需要证明保持适合你的框架的合理性?还有我想象的业务考虑因素包括:

    • 框架的长寿,或者是面对不断增长的jQuery可能会消失的mootools - 非常值得怀疑,因为他们刚刚发布了1.3 beta 1并且有2.0版本将在今年年底发布。 / LI>
    • 员工的成本和他们的培训(我想找到mootools程序员将比在他们的C.V /简历上打击jquery更困难)。
    • 在给定资源的情况下,在每个框架下维护和扩展系统所花费的时间(和成本)。

    这两个框架都很棒,但我相信你的兴趣最适合与mootools一起使用。

答案 1 :(得分:60)

就个人而言,jQuery完全符合我的需要。

我尝试在我的服务器端代码中完成大部分工作,结构良好:它具有适当的OOP,层和MVC架构。当我需要用Javascript做某事时,我发现(到目前为止)jQuery有我需要的东西。坦率地说,这分为三类:

  • 简单的DOM操作,通常在不点击服务器的情况下显示/隐藏内容。
  • Ajax调用,nuff说。
  • UI特权,包括模式弹出窗口,动画,从/到隐藏/显示的渐变过渡。我是一个硬核后端编码人,我在UI的东西 suck 。我真的很喜欢jQuery让我以编程方式制作看起来很吸引人的东西。

最重要的是,jQuery插件库非常庞大,我找到了很多简化客户端工作的库。好东西。

MooTools引入了OO思维,这很好,但不是我需要的。我希望将结构性保留在后端,而不必将这种思想引入我的客户端代码。对我来说,客户端代码是一个非常小的重点,从类的角度思考它是一种过度的方式,而且更多的工作。我觉得如果我使用我认为最适合MooToools的做法,我将构建两个应用程序而不是一个应用程序。

我认为这总结了为什么它如此受欢迎,特别是在这里。总的来说,我们是后端代码类型的人,jQuery让我们以编程方式创建一个吸引人的UI,让我们专注于我们的后端核心。

答案 2 :(得分:16)

我不喜欢将经典的面向对象强加到JavaScript上。有很多方法可以让一个JavaScript程序员使用Base2 for OO,而另一个使用Prototype或Moo或JS.Class或Joose。 Resig故意决定不向jQuery添加类,这鼓励人们找到更多本地JavaScript方法来解决问题。

因此,我更容易阅读其他jQuery编写者编写的JavaScript,并编写更容易让其他人阅读的jQuery代码。我通常不会尝试在JavaScript中模拟类OOP。相反,我动态创建对象并传递它们,我有很多对象数组。这很容易理解,我甚至发现自己把这种想法带到了OOP语言中!

就我所知,Moo很可能已经赶上了jQuery或者超越了它。但我无法花时间跟踪6或7个优秀的JavaScript库,看看哪匹马在前面。

我认为这主要是时间问题。当大量程序员加入AJAX时,jQuery是解决他们问题的热门新事物。

其他图书馆已基本赶上。 YUI,ExtJS,Dojo,Moo - 他们都很棒。但我不能全部使用它们。

我努力工作,试图找出我使用的库的新功能的后果。例如,jQuery在1.3版本中添加了Live事件。这实际上让我从许多页面切割代码。 Moo现在也提供这个,如果有的话,我怎么知道它发生了?

我确信Moo太棒了。我很乐意有时间学习它。但你看过Dojo了吗?我不得不在一个项目中使用它,并发现它已经从jQuery中提取了大部分伟大的想法。它有pubsub和对Comet的良好支持。

我同情你。但是你的程序员正在说话。学习jQuery对他们的职业生涯有好处,如果他们使用jQuery,还有更多的书籍,示例和其他程序员可以寻求帮助。

如果你决定去jQuery,那么在决定是否要使用OO库之前要认真思考。有一些很酷的(如JS.Class或Joose),但采取这一步意味着将自己与大多数JavaScript程序员编码的方式隔离开来。

答案 3 :(得分:11)

我现在一直在问自己同样的问题,只是试着绕过争论。在我读过的讨论中,压倒性的反应是“更广泛地采用 - 因此更好”。

我是广泛使用这两者的人。 JQuery在工作中(因为它被“更广泛采用”而被采用)和Mootools在个人项目中。结果,我经常发现自己在使用JQuery时感到瘫痪;无论是JSON支持,元素创建,事件处理......等等。在工作中,我发现自己长时间写了75个连锁事件......结果我觉得很脏。

我使用JQuery的主要优点是,插件和第三方开发人员关注的缺乏一致性或实践。当插件在结构上或其他方面没有一致性时,轶事“更多插件可用”确实无法帮助我。我花了几个星期的时间来学习“接受”的插件模型,即使在那时,我已经将自己的实用风格融入其中,因为我发现当前结构中存在错误和低效。可以说任何人都可以跳入并开始JQuerying它是'Pro'。但是,我更倾向于称之为'Con',因为你会看到30种不同的方法来完成某些事情,并且很难确定一个公认的标准。

那么“知道JQuery”是什么意思,这是否意味着你知道如何摇滚一点.hide()。show()。fadeIn()。fadeOut()?

当我不得不在工作中使用我的JS时,我想念一些Mootools。我的意思是没有Native JSON支持?拜托......

为了回应“广泛采用”的回应,我们都知道OSCommerce是最“Widely Adopted”的购物车,我们都知道这是一堆狗屎。我无法将JQuery与OSCommerce进行比较。我只是指出了“广泛采用”的错误。

至于插件,苹果的App商店有...... 100k的应用程序? 50,000是屁应用程序。当然有很多JQuery插件,但垃圾与价值的比例很高。

答案 4 :(得分:7)

jQuery使您可以访问清晰简洁的函数式编程方法。自从C#3.0中的(LINQ)方法链接发布以来,这对.NET程序员来说非常有效。因此,从一种语言到下一种语言的流程很容易。为了能够在DOM中查询对象或对象列表,对我们来说效果更好。 jQuery的选择能力首先使它具有吸引力,然后是它的可扩展性,当然所有内置的功能都很好。此外,背后的社区非常精彩,因为我首先想看看是否其他人做了什么,然后在没有找到解决方案的情况下尝试自己做。最后......但同样重要的是......微软将在Visual Studio 10中加入并支持它的事实很棒。 Moo Tools,Prototype等无法与上述所有内容竞争。

答案 5 :(得分:7)

无论如何,JS框架非常相似。如果您已经使用mootools一段时间了,请坚持下去。由于这个或那个原因,了解你的框架比选择一个框架要重要得多。

在我看来,对于高级javascript程序员来说,mootools更好,而对于非javascript程序员来说,jquery更好。这是我在阅读两份文件后的想法,请注意,我没有使用其中任何一种。 jQuery缺乏对javascript,函数绑定,对象克隆,线程堆栈等核心的支持。仅举几例。

答案 6 :(得分:5)

我也没有看过MooTools。但这是我对JQuery的观点:

  1. 一致的编程模型(有一种有效的JQuery方式)
  2. 优秀文档。当我开始时,JQuery有最好的文档。
  3. 广泛3rd party plugings
  4. Microsoft支持 - 我是一名asp.net开发人员,这有助于缓解客户的想法。此外,它现在附带我的工具。
  5. 很多入门指南。
  6. JQuery的网站看起来比MooTool的网站更好。对不起,我很抱歉,但确实如此。请记住,许多这些工具需要吸引设计师和开发人员。

答案 7 :(得分:5)

jQuery,就像任何框架一样,做它做的事情,如果它不符合你的需要,你应该使用别的东西。我不使用jQuery在javascript中进行复杂的编程,我使用它是因为它使DOM操作和CSS3样式的东西变得简单,95%的时间是我需要的。

答案 8 :(得分:5)

YAGNI。

是的,它在这里有点不合适,但这是jQuery比MooTools更大的基础。 MooTools带来的所有额外功能都很好,但YAGNI。

这不是最好的,而是关于满足 - 找到解决问题的适当解决方案。 jQuery易于使用,其主要目标是DOM操作。由于95%的人正在这样做只是为了操纵DOM,所以没有必要经历更长的MooTools学习曲线。 MooTools并没有为他们带来任何东西,因为jQuery不会用更少的努力来实现。

MooTools在您使用它之前需要更多,jQuery允许您快速拼凑一些东西。如果你开始编写大型,重型的js应用程序,你可能会遇到这种方法的一些缺点,但是再次95%的人写js并不这样做,所以那些事情对他们来说并不重要。他们使用服务器端语言来为DOM提供繁重的工作和javascript。

就此而言,他们对你的团队也无关紧要。逐点(jQuery first):

带您浏览列表

大型支持者社区 - 仅与项目略有关联。与团队有关的更多相关性,因为它与你的生活息息相关。如果遭遇不幸(拜托,上帝,不),你的公司就不见了,jQuery会让他们获得比MooTools更多的工作。

插件存储库 - 非常相关,因为它有助于防止重新发明轮子。

与Microsoft的ASP.NET和VisualStudio集成 - 如果您是.NET商店,则非常相关。事实上,如果你做.NET,那么这就应该是切换的理由。

微软,谷歌和其他人使用过 - 谁在乎呢?

现在为MooTools列表:

面向对象的框架与JS的经典OOP仿真 - 无关,除非您的项目的性质使其成为一个优势。我不知道你在建造什么,但对于网上商店来说,这只是很少相关。大多数网上商店没有足够的代码来使这个加分。

扩展的原生对象 - 再次与大多数网店无关

本机功能支持的浏览器之间的一致性更高。 - 相关

更简单的代码重用 - 这与大型存储库的jQuery优势有点冲突。一个大型存储库本身就是在重用代码。我怀疑你在使用一个狭窄的代码重用定义,这里可能不相关。我重用了很多我构建的jQuery代码,以及MT代码。

由万维网联盟,Palm和其他人使用。 - 不相关。如果你想在那里工作,唯一的关键是谁还在使用什么。与使用它的任何特定商店相比,有多少商店使用它更具相关性。

没有一种真正的方式来处理javascript编码。让您的偏见不受影响,并与您的团队坐下来,并让他们的偏见不受影响。谈谈你正在进行(并且想要承担)的具体项目类型的火鸡,以及适用于这些案例的每个图书馆的优势。 (他们如何处理其他案件并不重要,因为其他案件不存在。)你应该从中达成共识。

(YAGNI =你不需要它,如果我需要解释的话。)

答案 9 :(得分:4)

我选择使用jQuery作为我们的默认UI库,因为它不会扩展或以其他方式monkeypatch本机对象,与prototype.js或mootools不同。从文档角度来看,毫无疑问使用哪个框架。

答案 10 :(得分:2)

你有点自己说:

  

鉴于此,似乎MooTools做了jQuery所做的一切以及更多(有些事我在jQuery中无法做到,我可以在MooTools中做到)但是jQuery的学习曲线较小。

MooTools所做的大部分额外工作都是我们不需要的东西

正如您所说,jQuery更容易学习,这对于大多数人来说在选择框架时更为重要。

答案 11 :(得分:1)

我在JavaScript中不需要的是定义OOP和一些丑陋的对象模拟。

上次我检查MooTools(也许是1,5年前:-),它与浏览器不兼容,操纵多个选择。

所以jQuery对我来说完全没问题。

答案 12 :(得分:1)

jQuery不仅是一个很好的库,而且它的创建者John Resig也是Pro Javascript Techniques的作者。

我们办公室附有2-3本本书。

jQuery很小(故意这样),但可以通过插件添加功能。

答案 13 :(得分:1)

使我对mootools的体验相当不愉快的事情是API的文档和稳定性: 我根本无法找到与mootools-Version相关的文档。如果定义的API稳定,那么问题不会那么大。但由于某些功能在较新版本中消失(在搜索数小时后发现了ChangeLog),也无法进行迁移。在那之后,mootools不在我的竞争中。

与许多其他人一样,我不想将基于类的OOP引入简单的用户界面操作。多数民众赞成我使用jQuery:没有那么复杂的用户界面的东西。 当我必须构建丰富的浏览器端应用程序时,我总是会切换到提供各种即用型小部件的大解决方案(ExtJS,YUI,qooxdoo)。

答案 14 :(得分:1)

更大的用户社区以及更广泛的采用在比较提供类似功能和概念的工具/库时会产生很大的不同。较大的社区意味着更多的支持,更多的示例,更好的想法以及更多可重用的代码片段,这在您处理罕见情况时尤为重要 - 更有可能是其他人以前遇到过它。

其次,在我看过的基准测试中,jQuery比MooTools更快。

我也非常喜欢他们强调保留一个小核心并通过插件添加功能。防止核心库变得非常庞大和笨拙。

我从来没有亲自使用过MooTools,但我毫不怀疑它是一个非常棒的库,提供了一些可以接受的大部分jQuery功能或概念,但是第一点为我带来了蛋糕。

答案 15 :(得分:1)

另一个原因:将jquery出售给管理层更容易。在企业环境中进行基于asp.net的内部开发,神奇的词语是“Visual Studio支持它”。

答案 16 :(得分:0)

为什么人们开始使用传真机?在某个时刻,收益会呈指数级增长。

答案 17 :(得分:0)

Mootools,在使用jquery原型等时功能不正常或根本不起作用。同意绝对没有理由同时使用它们,但偶尔会出现在同一页面上(例如插件,幻灯片,小部件等)和事情都停止了。

这本身是不可接受的。所以jquery的所有道具都不会造成不必要的麻烦!

答案 18 :(得分:0)

我必须得到很多答案......伟大的文档和社区支持至关重要。我以前讨厌js编程并且会像试验那样避免它,但现在我已经完全接受了它因为jquery和快速的学习曲线。

并不总是关于谁拥有最好的技术!

答案 19 :(得分:0)

首先,这不是全部。有一个few other features as well。另一方面,不是每个人都使用它。但我不想打断一个好的咆哮。