为什么jQuery比其他JavaScript框架更受欢迎?

72

我负责管理一个程序员团队。我很重视我的员工的意见,但最近我们在Web项目中使用哪个框架上产生了分歧。

我个人比较偏爱 MooTools,但我的团队中有些人似乎想要迁移到 jQuery,因为它更广泛地被采用。但仅凭这一点不足以让我允许迁移。

我已经使用过 jQueryMooTools。这篇 文章 倾向于反映我对两个框架的感觉。 jQuery 对于 DOM 操作非常棒,但好像只能帮助你做到这一点。

就功能而言,jQueryMooTools 都允许轻松进行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');

使用 jQueryMooTools 都可以轻松实现 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');

使用 jQueryMooTools 都可以轻松实现 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提供以下附加功能:

  • 拥有庞大的支持者社区
  • 插件库
  • 与微软ASP.NET和VisualStudio集成
  • 被微软、谷歌和其他公司所使用

MooTools提供以下附加功能:

  • 面向对象框架,具有JS的经典OOP模拟
  • 扩展原生对象
  • 更高的浏览器兼容性,支持原生函数
  • 更易于重用代码
  • 被万维网联盟、Palm等公司所使用

因此,MooTools似乎可以做到jQuery能做的一切,并且还有更多功能(一些我在jQuery中无法实现,但我可以在MooTools中实现),但jQuery的学习曲线较低。

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

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


3
选择器、链式调用、插件、兼容其他JS库、易于编写自己的插件和选择器、标准化。我敢打赌你可以很快地编写一个OOP插件来使用jQuery。希望每个人都能转向jQuery,因为使用插件比使用别人复杂的JS代码更容易。 - IAdapter
4
如果以更客观的方式提出问题,我认为会减少负面反应。例如,你可以列举一些在MooTools中容易实现的事情,并说明如何在jQuery中解决它们。 - Tomalak
26
请有人重新打开这篇帖子。从这些讨论中可以学到很多东西。这种寻找关闭的做法已经太过分了。 - CDR
4
实际上,广泛认为在生态系统中仅使用一个平台或框架是不安全且不利于进步的。如果某个竞争对手占据了大多数市场份额,那么整个生态系统就无法发展[这就是为什么IE6能够长期主导市场的原因]。 - Andrew Moore
3
jQuery的庞大用户数量具有未来证明其适应新浏览器的优势。当浏览器升级或针对新手机推出新移动浏览器时,它们将会在更多使用jQuery而不是Moo的页面上进行测试。如果jQuery成为大多数页面所使用的“标准”,那么浏览器将不得不适应与之一起工作,而非相反。 - Nosredna
显示剩余6条评论
20个回答

2

你已经说了:

鉴于此,MooTools似乎做的事情比jQuery多(有些东西我无法在jQuery中实现而我可以在MooTools中),但是jQuery的学习曲线更小。

MooTools所做的大部分额外功能都是我们不需要的。

正如你所说,选择一个框架时,对于大多数人来说,更容易学习实际上更为重要,而 jQuery 更容易学习。


1

在 JavaScript 中,我绝对不需要面向对象编程和一些丑陋的对象模拟。

上次我检查 MooTools(大约1.5年前:-)),它与操作多个选择器存在浏览器不兼容性。

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


1

jQuery不仅是一个好用的库,而且它的创造者John Resig还以Pro Javascript Techniques的作者身份获得了一定的声誉。

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

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


1
让我对mootools的体验相当不愉快的是它的文档和API的稳定性:我根本找不到与当前使用的mootools版本相关的文档。如果API定义是稳定的,那么这个问题不会那么棘手。但由于一些在新版本中消失的功能(在搜索了数小时后才找到了ChangeLog),迁移也就不可能了。之后,mootools 对我来说已经出局了。
像许多其他人一样,我不想将基于类的OOP引入简单的用户界面操作中。这就是我使用jQuery的地方:处理不太复杂的用户界面内容。当我必须构建丰富的浏览器端应用程序时,我总是会转向提供各种现成小部件的大型解决方案(ExtJS、YUI、qooxdoo)。

1

更大的用户社区和更广泛的采用在比较提供类似功能和概念的工具/库时会产生很大的差异。更大的社区意味着更多的支持、更多的示例、更多的好点子和更多可重用的代码片段,这在你处理罕见场景时尤为重要——更有可能有人遇到过。

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

我也非常喜欢他们强调通过插件保持一个小核心并添加功能。这可以防止核心库变得非常庞大和难以控制。

我个人从未使用过MooTools,但我毫不怀疑它是一个非常棒的库,提供了与jQuery的大多数功能或概念相当的替代品,但第一点对我来说更重要。


关于速度声明:http://www.domassistant.com/slickspeed/ - Andrew Moore
我在Chrome和Firefox中进行了测试,结果MooTools比jQuery表现差得多。 - Nosredna
2
在多台机器上对5个主要浏览器进行多次测试后,我的平均结果是jQuery和MooTools表现相当,但jQuery有明显的优势。Prototype明显滞后,而YUI在所有测试中都是明显且不幸的输家。无论如何,这些测试似乎表明,在选择jQuery和MooTools之间,性能不应该是您主要关注的问题,因为MooTools足够好。感谢你提供这个很棒的链接,安德鲁! - Brian Lacy

1
另一个原因是:将 jQuery 推销给管理层更容易。在企业环境中进行内部 asp.net 开发,有个神奇的关键词:它受 Visual Studio 的支持。

我并不在意这个,因为我是管理层,而且我们也没有在开发ASP.NET。 - Andrew Moore
3
你问为什么jQuery更广泛被采用,而不是你为什么喜欢它。 - chris

0

为什么人们开始使用传真机?在某一点上,好处呈指数增长。


1
这并不是一个关于我是否应该使用传真机的问题,我见过传真机的实力并理解它们的必要性。我想知道为什么 HP 的传真机比三星的传真机更受欢迎,当三星的传真机拥有与 HP 相同甚至更多的功能。 - Andrew Moore
1
@Andrew Moore:很棒的比喻。 - Chase Wilson

0

首先,它不仅仅只有这些功能。还有一些其他 特性 可供使用 此外, 并不是每个人都在使用它。但我不想打断一个好的抱怨。


2
这不是诉苦,我两个框架都用过,也看到了 jQuery 的强大之处。但在 jQuery 中我能做的任何事情,在 MooTools 中都能做到,而反之则不成立。我并不讨厌 jQuery,只是不太理解它为什么如此广泛地被采用。 - Andrew Moore

0

我必须赞同大部分的答案... 文档和社区支持是至关重要的。我曾经讨厌 JavaScript 编程,像瘟疫一样避之不及,但现在因为 jQuery 和快速的学习曲线完全拥抱它了。

这并不总是与谁有最好的技术有关!


0

Mootools在使用jQuery原型等时无法正常运行或根本无法运行。毫无疑问,没有理由同时使用它们,但偶尔它们会出现在同一页上(例如插件、幻灯片、小部件等),导致功能停止。

这本身是不可接受的。因此,对于jQuery不会创建不必要的头痛给予一切赞扬!


4
这在最新版本中已经不再是真的了,而且,除了缺乏规划以外,绝对没有理由使用多个JavaScript框架。 - Andrew Moore

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接