为什么 jQuery 与其他 Javascript 框架相比被广泛采用？

我管理着一群程序员。我很重视我的员工的意见，但是最近我们对于在网络项目中使用哪个框架产生了分歧。

我个人喜欢 MooTools，但我的一些团队似乎想迁移到 JQuery，因为它被更广泛地采用。这本身并不足以让我允许迁徙。

我同时使用了 Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> jQuery 和 MooTools。这篇文章倾向于反映我对这两种框架的看法。Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> jQuery 非常适合 DOM 操作，但似乎仅限于帮助您这样做。

在特性方面，Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> 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');

Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> 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');

Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> 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 的集成
  • 被微软，谷歌和其他公司使用

MooTools 提供了以下额外功能:

  • 面向对象框架与 JS 的经典面向对象仿真
  • 扩展的本机对象
  • 浏览器之间对本机函数支持的更高一致性。
  • 更容易的代码重用
  • 被万维网联盟，Palm 和其他人使用。

有鉴于此，似乎 MooTools做的一切 Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> jQuery 所做的和更多(一些事情，我不能做在 Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> jQuery 和我可以在 MooTools) ，但 Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> jQuery 有一个较小的学习曲线。

所以问题是，为什么您或您的团队选择 Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> jQuery 而不是另一个 JavaScript 框架？

注意: 虽然我知道并且承认 Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> jQuery 是一个很棒的框架，但是还有其他的选择，我正在尝试做出一个决定，为什么 Rel = “ norefrer”> jQuery < a href = “ http://jQuery.com/”rel = “ norefrer”> jQuery 应该是我们的选择，而不是我们现在使用的(MooTools) ？

6976 次浏览
小开

JQuery 使您能够访问简洁明了的函数式编程方法。自从在 C # 3.0中发布了方法链接(LINQ)以来，这对于。NET 程序员。因此，从一种语言到下一种语言的流动很容易。能够在 DOM 中查询对象或对象列表，对我们来说效果要好得多。首先是 jQuery 的选择能力使它如此吸引人，然后是它的可扩展性，当然还有所有随之而来的内置特性都很好。此外，后面的社区也很棒，因为我首先查看别人是否做了什么事情，然后如果没有找到解决方案，我就尝试自己做。最后... 但肯定不是最不重要的... 事实上，微软将包括在 VisualStudio10和支持它是伟大的。Moo Tools，Prototype 等等都无法与以上所有的产品竞争。

小开

首先，这不是它的全部功能。有相当一个 很少 其他 特征 作为 好吧。另一方面，不是每个人都用它。但我不想打断你们的大吵大闹。

小开

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

小开

就个人而言，jQuery 正是我所需要的。

我尝试在服务器端代码中完成大部分工作，这些代码结构良好: 它具有适当的 OOP、层和 MVC 体系结构。当我使用 需要来处理 Javascript 时，我发现(到目前为止) jQuery 已经满足了我的需要。坦率地说，这可以分为三类:

  • 简单的 DOM 操作 ，通常在不影响服务器的情况下显示/隐藏内容。
  • Ajax 调用 ，niff 说。
  • UI 特效 ，包括模式弹出窗口、动画、从/到隐藏/显示的渐变。我是一个硬核后端编码家伙，我 烂透了在用户界面的东西。我真的很喜欢 jQuery 让我 程序化做的东西看起来很吸引人。

除此之外，jQuery 插件库非常庞大，我已经找到了不少可以简化我的客户端工作的库。好东西。

MooTools 引入了面向对象思维，这很好，但不是我需要的。我希望将我的结构都保留在后端，而不必将这种思想引入到我的客户端代码中。对我来说，客户端代码只是重点中的一小部分，从类的角度来考虑它是多余的，工作量更大。我觉得如果我使用我认为是 MooTools 的最佳实践的话，我将会构建两个应用程序，而不是一个。

我想这就是为什么它如此受欢迎，特别是在这里。总的来说，我们是后端代码类型的人，而 jQuery 让我们通过编程创建了一个吸引人的 UI，并让我们专注于后端核心。

小开

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

上一次我检查 MooTools (大概是1,5年前: ——) ，它有浏览器不兼容的操作多个选择。

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

小开

我也有一段时间没有看过 MooTools 了，但是我对 JQuery 的看法是:

  1. 一致的编程模型(有一种可行的 JQuery 方式)
  2. 优秀的文档 。
  3. 广泛的 第三方插头
  4. 微软的支持——我是一个 asp.net 开发人员，这有助于缓解客户的头脑。而且它现在和我的工具一起运输。
  5. 很多入门指南。
  6. JQuery 的网站看起来比 MooTool 的网站更好。我很抱歉这很重要，但确实很重要。请记住，这些工具中有许多需要吸引设计人员和开发人员。
小开

我不喜欢将经典的面向对象强加到 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 事件。这实际上让我可以从很多页面中删除代码。哞现在也提供这种服务吗? 如果真的发生了，我怎么知道它发生了？

我相信哞很棒。我很乐意有时间学习。你看过道场吗？我不得不在一个项目中使用它，发现它也吸收了 jQuery 的大部分好点子。而且它有 pubsub 和对 Comet 的良好支持。

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

如果您最终决定使用 jQuery，那么在决定是否添加 OO 库之前，请仔细考虑一下。有一些很酷的例子(比如 JS.Class 或 Joose) ，但是采取这一步意味着将自己与大多数 JavaScript 程序员的编码方式隔离开来。

小开

我选择使用 jQuery 作为我们的默认 UI 库，正是因为它不像 Prototype.js 或 mootools 那样扩展或修改原生对象。从文档的角度来看，使用哪个框架确实是没有问题的。

小开

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

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

小开

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

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

小开

JQuery 不仅是一个很好的库，它的创建者 John Resig 也是 Pro Javascript 技术的作者。

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

JQuery 很小(有意如此) ，但是可以通过插件将功能添加到其中。

小开

让我对 mootools 的体验相当不愉快的是 API 的文档和稳定性: 我就是找不到一个与 mootools-Version 有关的文档。如果定义的 API 是稳定的，就不会有那么大的问题。但是由于一些功能在新版本中消失了(搜索数小时后发现了一个 ChangeLog) ，迁移也不可能。从那以后 Mootools 就不再是我的竞争对手了。

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

小开

当比较提供类似功能和概念的工具/库时，更大的用户社区 和更广泛的采用会有很大的不同。更大的社区意味着更多的支持、更多的示例、更多的好主意和更多的可重用代码片段，当您在处理一个罕见的场景时，这一点尤其重要——更有可能是其他人以前遇到过这种情况。

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

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

我个人从未使用过 MooTools，但毫无疑问，它是一个非常棒的库，提供了一些可以接受的等价于大多数 jQuery 特性或概念的功能，但第一点对我来说很重要。

小开
最佳答案

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

  1. 您非常熟悉 mootools，并充分利用其 OOP 模型，使您的代码更容易管理和支持。
  2. 你会意识到 jQuery 的用途有些不同，它偏向于 DOM 操作和 AJAX，mootools 可以做 jQuery 做的所有事情。
  3. 听起来好像你不需要使用太多的第三方插件，这使得 jQuery 的受欢迎程度和支持程度变得不那么重要了。

总之，是炒作吗？JQuery 正在变成像“ AJAX”这样神奇的营销流行语。NET 和 Web 2.0ー这对他们来说很好，但是为什么 你需要证明继续使用对你来说这么好的框架呢？还有一些商业方面的考虑，我想包括:

  • 在 jQuery 不断发展壮大的背景下，mootools 是否会消失? 这一点非常值得怀疑，因为它们刚刚发布了1.3 beta 1,2.0版本正在酝酿之中，将于今年年底发布。
  • 员工成本和他们的培训(我想找到 mootools 程序员会比那些在简历上写上 jquery 的人更难)。
  • 在给定资源的每个框架下维护和扩展系统所花费的时间(和成本)。

这两个框架都很棒，但我相信使用 mootools 最符合您的利益。

小开

你自己也说过:

有鉴于此，MooTools 似乎可以做 jQuery 做的所有事情，甚至更多(有些事情我不能在 jQuery 中做，但是我可以在 MooTools 中做) ，但是 jQuery 的学习曲线较小。

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

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

小开

YAGNI.

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

这不是关于最好的，而是关于满足——找到手头问题的适当解决方案。JQuery 易于使用，其主要目标是 DOM 操作。因为95% 的人学习 javascript 只是为了操作 DOM，所以没有必要经历更长的 MooTools 学习曲线。MooTools 只是没有为它们带来任何 jQuery 不能以更少的努力提供的东西。

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

就此而言，他们可能对你的团队也不重要。要浏览这些列表，请逐点(首先是 jQuery) :

大量的支持者社区——只与项目有一点关联。对团队个人来说更重要，因为它代表着你死后的生活。如果不幸降临(上帝啊，不要) ，你的公司倒闭了，jQuery 会比 MooTools 给他们带来更多的工作。

插件存储库——非常相关，因为它有助于防止重造轮子。

与微软的 ASP.NET 和 VisualStudio 集成——如果你是一个。NET 商店。事实上，如果你这样做了，这本身就应该是你转换的理由。NET.

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

下面是 MooTools 列表:

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

扩展的本地对象——同样与大多数 Web 商店无关

浏览器之间更高的一致性以支持本机功能

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

被万维网联盟，Palm 和其他人使用。——无关紧要。关于谁在使用什么的唯一相关性就是你是否想在那里找到工作。有多少商店使用它比任何特定的商店使用它有更多的相关性。

没有一种真正的方法可以接近 javascript 编码。摆脱你的偏见，和你的团队坐下来，也摆脱他们的偏见。正确地谈论你正在进行的项目的具体类型(和想要进行的项目) ，以及应用到这些案例中的每个库的优势。(他们如何处理其他案件并不重要，因为其他案件并不存在。)你应该就此达成共识。

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

小开

Mootools，在使用 jquery 原型时不能正常工作或根本不能工作。同意绝对没有理由同时使用它们，但是偶尔它们会出现在同一个页面上(例如。插件、幻灯片、小工具等等)和东西停止工作。

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

小开

另一个原因是: 将 jquery 卖给管理层更容易。在企业环境中进行基于 asp.net 的内部开发，关键词是“它得到了 Visual Studio 的支持”。

小开

我一直在问自己这个同样的问题，现在只是试图理清我的头论点。随着我读到的每一次讨论，压倒性的反应是“更广泛地采用——因此更好”。

我是一个两者都广泛使用的人。工作中的 JQuery (被采用是因为它被“更广泛地采用”)和个人项目中的 Mootools。因此，我经常发现自己在使用 JQuery 时感觉有些残疾; 支持 JSON、创建元素、事件处理... ... 等等。在工作中，我发现自己连续写了75个事件... ... 结果我觉得很肮脏。

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

那么“了解 JQuery”意味着什么呢? 它是否意味着你知道如何摇滚一点.hide () . show () . fadeIn () . fadeOut () ？

当我不得不在工作中使用我的 JS 的时候，我想念我的 Mootools。我的意思是没有本地 JSON 支持？来吧..。

作为对“广泛采用”回应的回应，我们都知道 OSCommerce 是最“ 被广泛采用”的购物车，我们都知道那是一堆狗屎。我绝不会把 JQuery 和 OSCommerce 相提并论。我只是在指出“广泛采用”反应的错误。

至于插件，苹果应用程序商店有多少... 10万个应用程序？五万是放屁软件。当然 JQuery 有很多插件，但是垃圾和值的比例是很大的。

小开

为什么人们开始使用传真机? 从某种程度上来说，这种好处是成倍增加的。


提交答案