与其他 Javascript 框架相比，为什么 jQuery 被如此广泛地采用？ [关闭]答案

【问题标题】：Why is jQuery so widely adopted versus other Javascript frameworks? [closed]与其他 Javascript 框架相比，为什么 jQuery 被如此广泛地采用？ [关闭]
【发布时间】：2010-11-02 16:03:21
【问题描述】：

我管理着一组程序员。我确实重视员工的意见，但最近我们对于在 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 提供以下附加功能：

庞大的支持者社区
插件库
与微软的 ASP.NET 和 VisualStudio 集成
由 Microsoft、Google 和其他公司使用

MooTools 提供以下附加功能：

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

鉴于此，似乎 MooTools 做了所有 jQuery 做的事情，甚至更多（有些事情我在 jQuery 做不到> 我可以使用 MooTools），但 jQuery 的学习曲线较短。

所以问题是，您或您的团队为什么选择 jQuery 而不是另一个 JavaScript 框架？

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

【问题讨论】：

选择器，链接，插件，兼容其他JS库，易于编写自己的插件和选择器，标准。我敢打赌，你可以非常快地为 jQuery 编写 OOP 插件。我希望每个人都转向 jQuery，因为它的插件比别人复杂的 JS 代码更容易使用。
@Andrew Moore：我相信，以不那么固执己见的方式提出问题会减少负面的直觉反应。例如，您可以列出一些您在 MooTools 中轻松完成的事情以及如何在 jQuery 中解决它们。
有人请重新打开这篇文章。从这些讨论中可以学到很多东西。这种追尾的事情已经走得太远了
@01：实际上，一个被广泛接受的想法是，在一个生态系统中单独使用一个平台和/或框架是一件坏事，在安全和进步方面都是一件坏事。如果一个竞争对手占据了多数，那么生态系统就不会发展[这就是为什么我们有像 IE6 这样的怪物长期主导市场的原因]。
@Andrew Moore。不过，jQuery 的绝对数量优势在于它可以应对新的浏览器。当浏览器升级（以及新手机的新移动浏览器出现）时，它们将针对比 Moo 页面更多的 jQuery 页面进行测试。如果 jQuery 是大多数页面使用的“标准”，那么浏览器将不得不遵循它而不是相反。

标签： javascript jquery frameworks mootools

【解决方案1】：

我不喜欢将经典的面向对象强加到 JavaScript 上。有很多方法可以做到这一点，一个 JavaScript 程序员可能使用 Base2 进行 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 很棒。我很想有时间学习它。但是你看过道场吗？我不得不在一个项目中使用它，发现它也吸收了 jQuery 的大部分好主意。它有 pubsub 和对 Comet 的良好支持。

我很同情你。但是你的程序员说的是有道理的。学习 jQuery 对他们的职业生涯有好处，如果他们使用 jQuery，还有更多书籍、示例和程序员同行可以寻求帮助。

如果您最终决定使用 jQuery，请在决定是否使用 OO 库之前三思而后行。有一些很酷的（如 JS.Class 或 Joose），但采取这一步意味着将自己与大多数 JavaScript 程序员的编码方式隔离开来。

【讨论】：

我的首要任务不是我的员工职业，而是客户满意度。我们目前在三 (3) 个项目上使用 jQuery，与具有相同复杂性的 MooTools 项目相比，这些项目上的 javascript 似乎更难维护。
此外，MooTools 不会将经典的 OO 强加于 JavaScript。这是您可以使用或完全忽略的功能。实际上，MooTools OO 实现结合了原型继承和经典继承的精华！
如果您的内部经验表明您的 MooTools 项目比您的 jQuery 项目更好，那么您有一个很好的方法来证明您的案例。你能说出为什么 jQuery 项目会变坏吗？是缺少OOP模型吗？
@Andrew，我并不怀疑。只是说，当我看到 JavaScript 中的类时，它会让我大吃一惊，因为实现中有很多细微的变化。如果你坚持一个，我相信你很好。但是有多少百分比的 JavaScript 项目使用 MOO OOP？这是一个很小的百分比，我敢打赌。我不是说它有什么问题。我只是避开它，因为它不是语言的一部分——这是另一回事，它只会出现在我遇到的一小部分 JS 项目中。
实际上，jQuery 项目之所以失败，是因为一切都是通过 jQuery 对象完成的（或者，如果您在没有冲突的情况下运行，则为 $）。我们最终还得到了大约 75 个函数的链 [但我需要将其归咎于我的程序员]。

【解决方案2】：

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

您非常熟悉 mootools 并充分利用其 OOP 模型，使您的代码更易于管理和支持。
您意识到 jQuery 的目的有些不同，并且针对 DOM 操作和 AJAX 进行了调整，并且 mootools 确实可以完成 jQuery 所做的一切以及其他一些事情。
听起来好像您不需要以 3-rd 方插件的方式使用太多，这使得 jQuery 的受欢迎程度和支持变得不那么重要了。

底线，是炒作吗？ jQuery 正在变成像“AJAX”、.NET 和 Web 2.0 这样的神奇营销流行语之一——这对他们来说非常棒，但是为什么你需要证明继续使用对你非常有效的框架是合理的?还有一些我认为会涉及到的商业考虑：

framework 的寿命，或者 mootools 可能会在不断增长的 jQuery 面前消失 - 非常值得怀疑，因为他们刚刚发布了 1.3 beta 1 并且有 2.0 正在准备在今年年底发布。
员工和他们的培训成本（我想找到 mootools 程序员会比那些在他们的简历/简历上打 jquery 的人更难）。
在给定资源的情况下，在每个框架下维护和扩展系统所花费的时间（和成本）。

这两个框架都很棒，但我相信你的兴趣最好还是留在 mootools 上。

【讨论】：

这也是我做出的决定。最后我终于和 Mootools 说了。事实是，我看到许多开发人员通过将 jQuery 放在他们的简历上，并且完全不知道 document.getElementById() 做了什么，事实上，除了“它就是这样$ 符号'。这就是流行语技术的危险。人们开始把它放在简历中，即使他们只是模糊地知道它是什么。
鉴于最近的发展，您也可以两全其美。看看不久前 mootools 核心开发人员 Ryan Florence 实现了哪些精彩的魔法：ryanflorence.com/…

【解决方案3】：

人们为什么开始使用传真机？在某一点上，收益呈指数增长。

【讨论】：

这不是我是否应该使用传真机的问题，我已经看到了传真机的强大功能并了解了对它们的需求。我在问为什么三星的传真机拥有惠普的所有功能，而且还有些功能，为什么惠普传真机比三星的传真机更受欢迎。
@Andrew Moore：很好的比喻。

【解决方案4】：

一段时间以来，我一直在问自己同样的问题，只是想把我的头脑围绕在这个论点上。在我阅读的讨论中，压倒性的反应是“更广泛采用 - 因此更好”。

我是一个广泛使用两者的人。工作中的 JQuery（被采用是因为它被“更广泛地采用”）和个人项目中的 Mootools。结果，我经常发现自己在使用 JQuery 时感到手足无措。无论是 JSON 支持、元素创建、事件处理……等等。在工作中，我发现自己编写了长达 75 个事件的链……结果我觉得很脏。

不过，我对 JQuery 的主要不满是插件和 3rd 方开发人员缺乏一致性或实践。当插件之间在结构上或其他方面没有一致性时，传闻“有更多插件可用”真的对我没有帮助。我花了几个星期来学习“公认的”插件模型，即便如此，我还是将自己的实用风格融入其中，因为我发现当前结构中存在错误和效率低下。可以说这是一个“Pro”，任何人都可以加入并开始 JQuerying。但是，我更倾向于将其称为“骗局”，因为您会看到 30 种不同的方式来完成某事，而且很难确定一个公认的标准。

那么“Know JQuery”是什么意思，是不是意味着你知道如何摇滚一点.hide().show().fadeIn().fadeOut()？

当我不得不在工作中对我的 JS 进行黑帮时，我想念我的一些 Mootools。我的意思是没有原生 JSON 支持？来吧……

针对“广泛采用”的回应，我们都知道 OSCommerce 是最“Widely Adopted”的购物车，我们都知道那是什么垃圾。我绝不会将 JQuery 与 OSCommerce 进行比较。我只是指出“广泛采用”响应的错误。

至于插件，Apple 的 App Store 有什么... 100k 应用程序？ 50,000 个是放屁的应用程序。确实有很多 JQuery 插件，但是垃圾与有价值的比率很高。

【讨论】：

【解决方案5】：

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

【讨论】：

对此我并不关心，因为我是管理层，而且我们不是在开发 ASP.NET。
你问的是为什么 jQuery 被更广泛地采用，而不是你为什么喜欢它。

【解决方案6】：

Mootools，在使用 jquery 原型等时无法正常运行或根本无法运行。同意绝对没有理由同时使用它们，但有时它们确实会出现在同一页面上（例如插件，幻灯片，小部件等）和事情停止工作。

这本身就是不可接受的。所以 jquery 的所有道具都不会造成不必要的头痛！

【讨论】：

@Dheer: 最新版本不再如此，无论如何，除了缺乏规划之外，绝对没有理由使用多个 JavaScript 框架。

【解决方案7】：

亚格尼。

是的，这里有点不合适，但这是 jQuery 拥有比 MooTools 更大的基础的主要原因。 MooTools 带来的所有这些额外功能都很不错，但是 YAGNI。

这不是关于最好，而是关于满足——找到手头问题的适当解决方案。 jQuery 易于使用，它的主要目的是 DOM 操作。由于 95% 的人使用 javascript 只是为了操作 DOM，因此经历更长的 MooTools 学习曲线是没有意义的。 MooTools 并没有为他们带来任何 jQuery 不费吹灰之力提供的东西。

MooTools 在你使用它之前对你有更多的要求，jQuery 让你可以快速地将一些东西组合在一起。如果您开始编写大型、重型 js 应用程序，您可能会遇到这种方法的一些缺点，但同样 95% 的编写 js 的人不会这样做，所以这些事情对他们来说并不重要。他们使用服务器端语言处理繁重的任务，使用 javascript 处理 DOM。

就此而言，它们对您的团队也可能无关紧要。逐点介绍列表（首先是 jQuery）：

支持者的大型社区 - 与项目仅略微相关。与团队个人更相关，因为它与您之后的生活有关。如果不幸发生了（拜托，上帝，不），你的公司倒闭了，jQuery 比 MooTools 为他们提供了更多的工作。

插件存储库——非常相关，因为它有助于避免重新发明轮子。

与 Microsoft 的 ASP.NET 和 VisualStudio 的集成——如果您是 .NET 商店，则非常相关。事实上，如果您使用 .NET，仅此一项就应该是切换的原因。

被微软、谷歌和其他公司使用——谁在乎？

现在是 MooTools 列表：

带有经典 OOP 模拟 JS 的面向对象框架 - 无关紧要，除非您的项目的性质使其成为一个加分项。我不知道您在构建什么，但对于网上商店，这很少相关。大多数网上商店没有足够的代码来使其成为一个加分项。

扩展的原生对象——同样与大多数网上商店无关

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

更容易代码重用——这与大型存储库的 jQuery 优势有点冲突。一个大型存储库本身就可以重用代码。我怀疑您在这里使用了代码重用的狭义定义，这可能不相关。我已经重用了很多我构建的 jQuery 代码，以及 MT 代码。

由万维网联盟、Palm 和其他公司使用。 ——无关紧要。关于其他人在使用什么的唯一相关性是如果你想在那里找到一份工作。与使用它的任何特定商店相比，有多少商店在使用它。

没有一种真正的方法来处理 javascript 编码。消除您的偏见，并与您的团队坐下来，并消除他们的偏见。谈谈您正在开展（并希望开展）的具体项目类型以及每个图书馆在这些案例中的优势。（他们如何处理其他案件并不重要，因为其他案件不存在。）您应该由此达成共识。

（YAGNI = 你不需要它，如果我需要解释的话。）

【讨论】：

我不明白你为什么说 MooTools 要求你更多才能产生结果。如果您不想，则不需要将 OOP 与 MooTools 一起使用。通过代码重用，我不是指复制粘贴。我的意思是构建例如一个 PointedTips 类，然后可以通过执行类似 new PointedTips($('#myElement')) [jQuery has plugins instead: $('#myElement').PointedTips()] 之类的操作将其应用于元素。
MooTools 有一个第三方插件用于与 VS 集成。我应该说“开箱即用的集成”。但我们是一个 PHP 盒子。
你实际上是我的观点的一个很好的例子。在 MooTools 中创建一个类，在 jQuery 中编写 1-2 行 js。如果您的目标是用 js 构建一个复杂的应用程序，MT 的方法很合适，但大多数人只是为了实现特殊效果而使用 js，而这通常是一行 jQuery 代码。我并不是说 jQuery 总是更好，我说的是“课程的马”。很多时候你想要做的事情可以在 jQuery 中更快更容易地完成，因此它很受欢迎。

【解决方案8】：

你自己说吧：

鉴于此，MooTools 似乎可以完成 jQuery 所做的一切，甚至更多（有些事情我在 jQuery 中无法做到，而我在 MooTools 中可以），但 jQuery 的学习曲线更短。

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

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

【讨论】：

【解决方案9】：

更大的用户社区和更广泛的采用在比较提供相似功能和概念的工具/库时会产生很大的不同。更大的社区意味着更多的支持、更多的示例、更多的好想法和更多可重用的代码 sn-ps，这在您处理罕见场景时尤其重要——其他人以前可能遇到过这种情况。

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

我也非常喜欢他们强调保持小核心并通过插件添加功能的做法。防止核心库变得非常庞大和笨重。

我从未亲自使用过 MooTools，但我毫不怀疑它是一个出色的库，提供了与大多数 jQuery 功能或概念相当的可接受的等价物，但第 1 点对我来说很重要。

【讨论】：

关于速度声明：domassistant.com/slickspeed
我在 Chrome 和 Firefox 中测试过，MooTools 的表现比 jQuery 差很多。
在多台机器上对所有 5 种主要浏览器进行多次测试后，我的平均结果往往是 jQuery 和 MooTools 的性能相当，但明显有利于 jQuery。原型明显滞后，而 YUI 在所有测试中都是一个明显而悲惨的失败者。无论如何，这些测试似乎表明，在 jQuery 和 MooTools 之间进行选择时，性能不应该是您的主要考虑因素，因为 MooTools 本身就足够好。感谢安德鲁的漂亮链接！

【解决方案10】：

让我对 mootools 的体验相当不愉快的是文档和 API 的稳定性：我根本无法找到与正在使用的 mootools-Version 相关的文档。如果定义的 API 是稳定的，那么问题就不大了。但是由于某些功能在较新的版本中消失了（经过数小时的搜索发现了 ChangeLog），因此也无法进行迁移。在那之后，mootools 就退出了我的竞争。

与许多其他人一样，我不想将基于类的 OOP 引入简单的用户界面操作。这就是我使用 jQuery 的目的：不是那么复杂的用户界面。当我必须构建丰富的浏览器端应用程序时，我总是会切换到提供各种即用型小部件的大型解决方案（ExtJS、YUI、qooxdoo）。

【讨论】：

【解决方案11】：

jQuery 不仅是一个不错的库，它的创建者 John Resig 作为Pro Javascript Techniques 的作者也有一些街头声誉。

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

jQuery 很小（故意如此），但可以通过插件添加功能。

【讨论】：

【解决方案12】：

无论如何，JS 框架非常相似。如果您使用 mootools 已经有一段时间了，请坚持下去。了解你的框架比因为这个或那个而选择一个更重要。

在我看来，mootools 更适合高级 javascript 程序员，而 jquery 更适合非 javascript 程序员。这就是我在阅读了这两个文档后的想法，请注意，我没有使用它们中的任何一个。 jQuery 缺乏对 javascript 核心、函数绑定、对象克隆、线程堆栈等的支持。

【讨论】：

【解决方案13】：

我必须支持很多答案...出色的文档和社区支持至关重要。我曾经讨厌 js 编程，会像瘟疫一样避免它，但现在我完全接受了它，因为 jquery 和快速的学习曲线。

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

【讨论】：

【解决方案14】：

我选择使用 jQuery 作为我们的默认 UI 库正是因为它不像prototype.js 或mootools 那样扩展或以其他方式猴子补丁原生对象。进入文档角度，确实没有关于使用哪个框架的问题。

【讨论】：

我刚刚查看了 MooTools 的网站。原生类型的增加让我很紧张，但我喜欢他们做哈希的方式。 mootools.net/docs/core/Native/Hash

【解决方案15】：

我也有一段时间没有看 MooTools 了。但这是我对 JQuery 的看法：

一致的编程模型（有一种 JQuery 方式可以工作）
优秀的文档。当我开始使用 JQuery 时，那里有最好的文档。
广泛的3rd party plugings
Microsoft 支持 -- 我是一名 asp.net 开发人员，这有助于减轻客户的顾虑。此外，它现在随我的工具一起提供。
大量入门指南。
JQuery 的网站看起来比 MooTool 的网站好。对不起，这很重要，但确实如此。请记住，其中许多工具需要吸引设计师和开发人员。

【讨论】：

【解决方案16】：

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

我上次检查 MooTools 时（可能是 1.5 年前 :-)，它的浏览器与操作多选不兼容。

所以 jQuery 在我看来完全没问题。

【讨论】：

【解决方案17】：

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

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

简单的 DOM 操作，通常在不访问服务器的情况下显示/隐藏内容。
Ajax 调用，nuff 说。
UI 特权，包括模式弹出窗口、动画、从/到隐藏/显示的淡入淡出过渡。我是一个铁杆后端编码人员，我很讨厌 UI 方面的东西。我真的很喜欢 jQuery 让我以编程方式制作看起来很吸引人的东西。

除此之外，jQuery 插件库非常庞大，而且我发现了很多简化客户端工作的库。好东西。

MooTools 引入了 OO 思维，这很好，但不是我需要的。我想在后端保持我的结构化，而不必将这种想法引入我的客户端代码。对我来说，客户端代码只是重点的一小部分，从类的角度考虑它是一种矫枉过正的做法，而且工作量更大。如果我使用我认为 MooTools 的最佳实践，我觉得我会构建两个应用程序而不是一个。

我认为这总结了它如此受欢迎的原因，尤其是在这里。总的来说，我们是后端代码型的人，而 jQuery 让我们以编程方式制作吸引人的 UI，并让我们专注于后端核心。

【讨论】：

+1 在简单的 UI 优点上——我讨厌 UI 编程，并且能够包含一个或两个插件，添加几行 JS，并将带有表单的简单 div 转换为模态弹出窗口只是 awesome
一个简单的问题：显示/隐藏元素与服务器有什么关系（参见“简单的 DOM 操作”）？
自我注意：在固执己见的线程中的建设性答案仍然会让你投反对票：/
@Andrew Moore：感谢 :) 我很惊讶在这里得到了 3 票反对票——我希望人们能发表他们的推理，这样我就可以更好地充实答案。我希望这会有所帮助，而且我肯定有兴趣阅读您对我发布的内容的想法。批评占主导地位（甚至不占主导地位）的范式是件好事！
我最赞成的答案也是迄今为止我最反对的答案。它仍然有 14 票。有些人只是讨厌你赞扬他们不喜欢的技术或提到他们喜欢的技术的缺陷，然后他们通过投票来发泄这种仇恨。

【解决方案18】：

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

【讨论】：

【解决方案19】：

一方面，这还不是全部。有不少few other features as well。另一方面，不是每个人都使用它。但我不想打断你的好话。

【讨论】：

这不是咆哮，我都用过，看到了 jQuery 的强大。但是在 jQuery 中没有什么是我在 MooTools 中不能做的，而相反的情况则不然。我并不讨厌 jQuery，我只是不明白为什么它被如此广泛地采用。

【解决方案20】：

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

【讨论】：

jQuery 背后的社区很棒（事实上它也集成在 VS 中），我承认，但 MooTools 具有与 jQuery 相同的选择功能。