为什么jQuery如此广泛地采用与其他Javascript框架？
我pipe理一群程序员。 我非常重视员工的意见，但最近我们对于在networking项目中使用哪个框架进行了分类。
我个人很喜欢MooTools ，但是我的一些团队似乎想迁移到jQuery，因为它被广泛采用。 这本身不足以让我进行移民。
我用过jQuery和MooTools 。 这篇特别的文章倾向于反映我对这两个框架的感受。 jQuery非常适合DOM操作，但似乎仅限于帮助您执行此操作。
特性明智的是， jQuery和MooTools都允许简单的DOMselect和操作 ：
// 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都允许简单的DOManimation ：
// 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提供以下额外function：
- 大型支持者社区
- 插件库
- 与微软的ASP.NET和VisualStudio集成
- 由微软，谷歌和其他人使用
MooTools提供以下额外function：
- 面向对象的框架与经典的面向JS的OOP仿真
- 扩展的本机对象
- 浏览器之间的本地function支持更高的一致性。
- 更简单的代码重用
- 由万维网联盟，Palm和其他人使用。
鉴于此，看起来MooTools可以完成jQuery所做的所有工作（我在jQuery中无法做到的一些事情，而且我可以在MooTools中完成 ），但jQuery的学习曲线较小。
所以问题是，为什么你或你的团队selectjQuery而不是另一个JavaScript框架呢？
注意：虽然我知道并承认jQuery是一个很好的框架，但还有其他的select，我试图做出决定，为什么jQuery应该是我们的select，而不是我们现在使用的（ MooTools ）？
这是一个奇怪的问题…我的印象是…
- 您对mootools非常熟悉，并充分利用其OOP模型，使您的代码更易于pipe理和支持。
- 你意识到jQuery的目的有点不同，并且针对DOM操作和AJAX进行了调整，而且mootools确实做了jQuery所做的一切，然后做了一些。
- 听起来好像你不需要太多的使用第三方插件的方式，这使得jQuery的stream行和支持点不那么重要。
底线，这是炒作吗？ jQuery正在变成这些神奇的营销专业术语之一，如“AJAX”，.NET和Web 2.0–这对他们来说是非常棒的，但是为什么你需要certificate自己能够适合你的框架呢？ 还有我想象中的业务考虑将包括如下内容：
- 框架长寿，还是mootools可能会消失在面对不断增长的jQuery – 非常可疑，看到他们刚刚发布1.3testing版1，并有2.0在年底发布的pipe道。
- 工作人员的成本和他们的培训（我想，findmootools程序员比在他们的简历/简历上拍jquery更困难）。
- 在给定资源的情况下在每个框架下维护和扩展您的系统的时间（和成本）。
这两个框架是伟大的，但我相信你的利益是最好的留在mootools服务。
就个人而言，jQuery正是我所需要的。
我尝试在我的服务器端代码中完成大部分工作，这些代码结构良好：具有适当的OOP，图层和MVC体系结构。 当我需要用JavaScript做些什么的时候，我发现（到目前为止）jQuery有我需要的东西。 坦率地说，这分为三类：
- 简单的DOM操作 ，通常显示/隐藏的东西没有击中服务器。
- 阿贾克斯呼吁 ，nuff说。
- UI津贴 ，包括模式popup，animation，淡入淡出到/隐藏/显示。 我是一个硬核后端编码的人，我吮吸 UI的东西。 我真的很喜欢jQuery让我编程的东西，看起来很有吸引力。
最重要的是，jQuery插件库非常庞大，我find了很多简化客户端工作的库。 好东西。
MooTools介绍面向对象的思想，这很好，但不是我所需要的。 我想在后端保持我的结构性，而不必将这种想法介绍给我的客户端代码。 对我来说，客户端代码是一个非常小的重点，并从一个类的angular度思考它的方式是矫枉过正，方式更多的工作。 我觉得如果我要使用MooToools的最佳实践，我会构build两个应用程序而不是一个应用程序。
我想这个总结为什么它如此受欢迎，尤其是在这里。 总的来说，我们是后端的代码types的人，jQuery让我们编程吸引人的用户界面，让我们专注于我们的后端核心。
我不喜欢将经典的对象方向强加到JavaScript上。 有很多方法可以做到这一点，一个JavaScript程序员可能会使用Base2的OO，而另一个使用Prototype或Moo或JS.Class或Joose。 Resig故意决定不把类添加到jQuery中，这就鼓励人们find更多原生的JavaScript方法来解决问题。
因此，我更容易阅读JavaScript其他jQuery编写者编写的代码，并编写易于其他人阅读的jQuery代码。 我通常不尝试在JavaScript中模拟类OOP。 相反，我创build对象，并传递它们，并有很多对象数组。 这很容易理解，我甚至发现自己把这种想法带到OOP语言！
据我所知，Moo可能已经赶上了jQuery或者超越了它。 但我不能把时间花在跟踪6,7个伟大的JavaScript库上，看看哪个马在前面。
我认为这主要是一个时间问题。 当大量的程序员跳入AJAX时，jQuery是解决他们问题的最新酷酷东西。
其他图书馆很大程度上赶上了。 YUI，ExtJS，Dojo，Moo–他们都很棒。 但是我不能全部使用它们。
我努力工作，努力弄清楚我使用的图书馆的新function的后果。 例如，jQuery从1.3开始添加了Live events。 这实际上让我从很多页面切割代码。 Moo现在也提供这个服务吗？如果是的话，我怎么知道呢？
我确定Moo真棒。 我很想有时间去学习它。 但是你看过Dojo吗？ 我不得不在一个项目中使用它，并发现它也从jQuery中获得了绝大多数的好点子。 它有pubsub和彗星的良好支持。
我很同情你。 但你的程序员说话有道理。 学习jQuery对他们的职业生涯非常有利，如果他们使用jQuery，还有更多书籍，示例和其他程序员可以寻求帮助。
如果你决定去jQuery，那么在决定是否join一个面向对象的库之前要先好好想一想。 有一些很酷的（比如JS.Class或者Joose），但是采取这一步意味着将自己从大多数JavaScript程序员的代码中分离出来。
我一直在问自己这个同样的问题，只是试图把我的头围绕在论点上。 而且我经常读到讨论，反应热烈的是“更广泛地采用 – 因此更好”。
我是一个广泛使用的人。 JQuery在工作（因为它被“更广泛地采用”而被采用）和Mootools在个人项目上。 结果，我在使用JQuery的时候总是感觉自己陷入了瘫痪; 无论是JSON支持，元素创build，事件处理…等等。 在工作中，我发现自己写了75个事件长的链条，结果我觉得很肮脏。
JQuery的主要缺点是插件和第三方开发人员缺乏一致性或实践。 轶事“更多的插件可用”真的不帮助我，当插件结构之间没有一致性或其他。 我花了几个星期的时间去学习“被接受”的插件模型，即使如此，我也在自己的实用风格中join了自己的实用风格，因为我发现当前结构中存在错误和低效率。 可以这样说，任何人都可以跳进去，然后开始J运行。 不过，我更倾向于称之为“同意”，因为你会看到30种不同的方式来完成某件事情，而制定一个公认的标准是很困难的。
那么这对于“知道JQuery”意味着什么，这是否意味着你知道如何使用一个.hide（）。show（）。fadeIn（）。fadeOut（）？
当我必须在我的JS工作stream氓上，我想念我一些Mootools。 我的意思是没有本机JSON支持？ 来吧……
为了回应“广泛采纳”的回应，我们都知道OSCommerce是最被“ 广泛采用 ”的购物车，我们都知道这是多么的垃圾。 我没有办法比较JQuery到OSCommerce。 我只是指出了“广泛采纳”的反应的错误。
至于插件，苹果App Store有什么… 100K的应用程序？ 50,000个是放屁应用程序。 当然，JQuery有很多插件，但是垃圾和价值的比例是非常好的。
jQuery为您提供了清晰简洁的函数式编程方法。 由于在C＃3.0（LINQ）中的方法链接的释放，这对于.NET程序员来说非常合适。 所以从一种语言到另一种语言的stream程很容易。 为了能够查询DOM对象或对象列表，对我们来说效果更好。 首先是jQuery的select能力，使得它非常有吸引力，然后它的可扩展性，当然所有内置的function都很好。 另外，背后的社区是非常好的，我首先要看看是否有其他人做了什么，然后尝试自己做，如果找不到解决scheme。 最后……但肯定不是不重要的……微软将要包含在Visual Studio 10中并支持它的事实是很棒的。 Moo Tools，Prototype等仅仅是无法与上述所有产品竞争。
无论如何，JS框架非常相似。 如果你一直在使用mootools一段时间，坚持下去。 了解你的框架比select一个更重要，因为这个或那个。
在我看来，mootools更适合高级javascript程序员，而jquery更适合非JavaScript的程序员。 这是我读完这两份文件后所想到的，请注意，我没有使用任何文件。 jQuery缺乏对javascript的核心，函数绑定，对象克隆，线程堆栈等等的支持。
像任何框架一样，jQuery做它所做的事情，如果它不适合你的需求，你应该使用其他的东西。 我不使用jQuery在JavaScript中做复杂的编程，我使用它，因为它使DOM操作和CSS3风格的东西简单，95％的时间，这是我所需要的。
我还没有看过MooTools。 但是这里是我对JQuery的要点：
- 一致的编程模型（有一个工作的JQuery方式）
- 优秀的文档 。 当我开始时，JQuery拥有最好的文档。
- 广泛的第三方插件
- 微软支持 – 我是一个asp.net开发人员，这有助于缓解客户的头脑。 再加上我现在用我的工具。
- 很多入门指南。
- JQuery的网站看起来比MooTool的网站好看。 我很抱歉，但事实确实如此。 请记住，许多这些工具需要吸引devise师以及开发人员。
YAGNI。
是的，这里有点不合适，但这是jQuery比MooTools更大的主要原因。 所有这些MooTools带来的额外function都不错，但YAGNI。
这并不是最好的，而是关于满足 – find解决手头问题的充分办法。 jQuery易于使用，其主要目标是DOM操作。 由于95％的人捡起JavaScript只是为了操纵DOM，所以通过更长的MooTools学习曲线是没有意义的。 MooTools根本没有为他们带来任何东西，jQuery没有提供更less的工作。
在你使用之前，MooTools对你有更多的要求，jQuery可以让你快速地把东西扔在一起。 如果你开始编写大型，重型的js应用程序，你可能会碰到这种方法的一些缺点，但是95％的人写js不会这么做，所以这些对他们来说并不重要。 他们使用服务器端的语言来处理繁重的工作，而使用JavaScript来处理DOM。
对于这个问题，他们也许对你的团队无关紧要。 带你通过列表，逐点（jQuery第一）：
大型支持者社区 – 与项目只有一点相关。 与团队更亲密的关系，因为它跟你的生活说话。 如果不幸的事情发生（拜托，上帝，否），你的公司不在，那么jQuery比MooTools获得更多的工作。
插件库 – 非常相关，因为它有助于防止重新发明轮子。
与微软的ASP.NET和VisualStudio集成 – 如果你是一个.NET商店非常相关。 事实上，如果你使用.NET，这应该是切换的原因。
由微软，谷歌和其他人使用 – 谁在乎？
现在对于MooTools列表：
面向对象的框架与经典的面向JS的OOP仿真 – 无关紧要，除非项目的性质使其成为一个优点。 我不知道你在build什么，但是对于网店来说，这只是很less相关的。 大多数networking商店没有足够的代码来使这个加分。
扩展的本地对象 – 对于大多数networking商店来说也是不相干的
浏览器之间的本地function支持更高的一致性。 – 相关
更简单的代码重用 – 这与大型资源库的jQuery优势相冲突。 一个大版本库本身就是用来重复使用代码的。 我怀疑你正在使用代码重用的狭义定义，在这里，可能不相关。 我已经重用了很多我已经构build的jQuery代码，以及MT代码。
由万维网联盟，Palm和其他人使用。 – 无关紧要 唯一相关的是如果你想在那里工作的话，还有谁还在用呢？ 有多less商店使用它比任何特定的商店使用它有更多的相关性。
没有一个真正的方法来处理JavaScript编码。 把你的偏见排除在外，和你的团队一起坐下来，让自己的偏见也消失。 与土耳其谈谈您正在从事（并希望进行）的具体项目types以及适用于这些案例的每个图书馆的优势。 （他们如何处理其他案件并不重要，因为其他案件不存在）。你应该从中得出一个共识。
（YAGNI =你不需要，如果我需要解释的话）
我select使用jQuery作为我们的默认UI库，因为它不扩展或以其他方式monkeypatch本地对象，不像prototype.js或mootools。 踢文档的angular度，真的是没有问题，使用哪个框架。
你有点自己说：
鉴于此，看起来MooTools可以完成jQuery所做的所有工作（我在jQuery中无法做到的一些事情，而且我可以在MooTools中完成），但jQuery的学习曲线较小。
MooTools所做的大部分额外的东西是我们不需要的东西。
正如你自己所说，jQuery更容易学习，对于大多数人来说，select一个框架实际上更重要。
我不需要JavaScript的是定义OOP和一些丑陋的对象模拟。
上一次我检查MooTools（也许1,5年前:-)，它有操纵多个select的浏览器不兼容。
所以jQuery对我来说是完全可以的。
jQuery不仅是一个很好的库，而且它的创build者John Resig也是Pro Javascript Techniques的作者 。
我们的办公室里有2-3本这本书。
jQuery很小（故意这样），但可以通过插件添加到它的function。
使我的经验与mootools一个相当不愉快的事情是API的文档和稳定性：我根本无法find与正在使用的mootools-Version相关的文档。 如果定义的API是稳定的，那么不会有太大的问题。 但是由于一些function在新版本中消失了（在search几个小时后发现了ChangeLog），迁移也是不可能的。 那之后，莫托尔斯已经不在了我的面前。
像许多其他人一样，我不想将简单的用户界面操作引入基于类的OOP。 那就是我使用jQuery的原因：没有那么复杂的用户界面的东西。 当我必须构build丰富的浏览器端应用程序时，我总是会转向提供各种可以使用的小部件的大型解决scheme（ExtJS，YUI，qooxdoo）。
当比较提供类似function和概念的工具/库时， 更大的用户社区和更广泛的采用会产生巨大的差异。 更大的社区意味着更多的支持，更多的例子，更多的好主意，更多的可重用的代码片段，这在您处理罕见的情况时尤为重要 – 更有可能是其他人遇到过。
其次，在我看到的基准testing中，jQuery比MooTools更快。
我也非常喜欢通过插件保持一个小核心和增加function。 防止核心库变得非常庞大而笨拙。
我从来没有亲自使用过MooTools，但是我毫不怀疑它是一个非常出色的库，它提供了一些与大多数jQuery特性或概念相当的可接受的等价物，但是第一点是为我准备的。
另一个原因：向pipe理层销售jquery更容易。 在企业环境中进行内部的，基于asp.net的开发，魔术字是“Visual Studio支持的”。
首先，这不是全部。 还有其他一些 function 。 另外，不是每个人都使用它。 但我不想打断一个好的咆哮。
我必须回答很多答案…伟大的文档和社区支持是至关重要的。 我曾经讨厌js编程，并会避免它像plauge，但现在我已经完全拥抱它，因为jQuery和快速的学习曲线。
并不总是关于谁拥有最好的技术！
Mootools，使用jquery原型时不能正常工作或者根本不起作用。同意绝对没有理由同时使用它们，但偶尔它们会在同一页面上出现（例如插件，幻灯片，小部件等等）和事情停止工作。
这本身是不可接受的。 所以所有道具为jquery不创造不必要的头痛！
为什么人们开始使用传真机？ 在某一点上，益处呈指数增长。
