为什么 facebook 不使用 jQuery（或类似的）？ [关闭]答案

【问题标题】：Why doesn't facebook use jQuery (or similar)? [closed]为什么 facebook 不使用 jQuery（或类似的）？ [关闭]
【发布时间】：2011-07-23 15:31:31
【问题描述】：

Facebook 很大程度上基于 JavaScript。为什么它不依赖 jQuery（或任何其他类似的库）？

编辑：为什么要结束这个问题？这不是主观的。 facebook 不使用 jQuery（或任何其他框架）是有原因的，我要求。

【问题讨论】：

这本质上是相当主观的。为什么不使用 MooTools？优？可能是因为他们必须这样做，因为早期的决定或当前的要求，或者董事会董事支持新的自定义设置。这不是问题。
因为 John Resig 为 Mozilla 工作，而不是 Facebook。
为什么要结束这个问题？这不是主观的。 facebook 不使用 jquery（或任何其他框架）是有原因的
@yes123：没有 Facebook 开发者的意见，这个问题无法客观回答，我们只能提供推测。
希望马克扎克伯格能回答这个问题。让我邀请（-_-'）

标签： javascript jquery facebook frameworks

【解决方案1】：

简短回答：您必须询问 Facebook 开发团队。

最佳猜测：

拥有大型软件产品（和成熟的代码库）的大公司往往会坚持使用有效的方法——即使已经有一个流行的框架可供迁移。请记住，Facebook 早在 JQuery 被认为是标准之前就已经存在了。
他们可能会在未来很多年里支持他们现有的代码。并且“切换”到新语言或框架的成本效益比可能太低，无法保证重写或转换。恰当的例子：Sun 没有将太多的 Solaris 移植到 Java。只有少量的 Windows 是用 C# 编写的。
在 2011 年，当我第一次写这篇文章时：如果你真的看 Facebook 的网站，他们的 DOM 结构并没有那么复杂。他们没有很多动画。它们不是一个非常重的 AJAX 站点。鉴于此，JQuery 可能对他们没有吸引力。 更新 - 2015 年：FB 比几年前更有活力。所以这里的第 3 名的重量与 2011 年不同。
此外，当您有多个团队为单个软件产品（或网站）做出贡献时，每个人都在同一个框架上进行标准化非常重要。如果每个团队都集成了不同的框架，那么代码很快就会因为所有这些不同的库的链接而变得臃肿。对于网站，这意味着页面加载时间更长。
JQuery 旨在支持最大的浏览器集。在某些情况下，这可能意味着“针对最低公分母进行优化”。 FB 可能希望在可用时利用更新的浏览器功能。
FB 可能不想太“锁定”到 JQuery。众所周知，JQuery 在一些处于测试阶段的较新浏览器中存在一些错误。现在，如果 Facebook 有一百万行基于 JQuery 1.6 的代码，那么在 IE 10、FF 5 和 Chrome 12 上运行时可能会出现问题。为了完成这项工作，他们必须升级到 JQuery 1.7，但这意味着需要在整个代码库中进行大量测试。
最后，他们可能拥有比 JQuery 更好的内部功能。如果 Facebook 已经有一个基于发出页面请求的浏览器输出 HTML+JS 的服务器端框架，我不会感到惊讶。

我知道这些答案都不是很受欢迎。您团队中的哪个开发人员不想切换到最新最好的技术？但是，当您考虑与您的业务规模相关的业务案例和支持框架的成本时，您必须谨慎行事。

【讨论】：

我认为这个答案是有道理的。
如果他们有一百万行自己的代码，无论如何他们都必须对其进行测试。除了automated testing之外，像 jQuery 这样的开源库已经过数百万的测试。
我认为数字 7 最有可能。如果他们没有框架，我会感到惊讶。 jQuery 带有许多 facebook 可能不需要的特性。当涉及到每天数十亿的页面加载时，每个字节都很重要！合理的做法是拥有一个能够带来所需功能的确切数量的框架。不多也不少
我觉得这里最正确的是7号

【解决方案2】：

因为他们选择做自己的事？

【讨论】：

【解决方案3】：

出于您所说的确切原因，Facebook 不依赖库，它大量基于 javascript。因此，他们希望完全控制和自定义他们编写的代码。这样他们就可以编写特定于其应用程序的解决方案，这也可以提高效率。效率对于所有网站（尤其是 Facebook）来说都是一件大事，通过这种方式，他们可以轻松地编辑代码以按照自己的喜好执行。

【讨论】：

这里没有提到缓存，这是一个非常重要的因素。你不可能在每次请求时都从远程服务器加载 jQuery！
他们至少使用内部库。他们已经向公众发布了他们的Animation library。
@Peter，Facebook 可以在自己的服务器上托管 jQuery。即使他们使用了 Google 的 AJAX CDN 之类的东西，为什么每次请求都会加载它？有时甚至会在有人访问 Facebook 之前加载。
@matthew：该库已完全关闭。文档的内部链接指向必应搜索。失败
@Matthew：这正是我的意思。我想知道为什么@Mike 似乎认为每次请求都会从服务器加载 jQuery。当然会被缓存。

【解决方案4】：

因为他们自己构建他们需要的东西，所以 jQuery 也是 Javascript。

【讨论】：

【解决方案5】：

如果你想要我的意见：

我认为唯一的原因是因为 Facebook 于 2003/2004 年推出，jQuery 于 2006 年推出。那时为时已晚，无法将所有 js 重新转换为 jQuery

【讨论】：

【解决方案6】：

在我个人的经验中，因为很多大公司觉得他们太好了，无法使用框架，他们觉得有必要将所有东西都保留在“内部”

【讨论】：

您曾在多少家大公司工作过？ xD
就我个人而言，1。但我确实认识很多人：P
不，但说真的，根据我的经验，它通常会归结为这样的事情。或者品牌。他们不希望人们认为他们使用 3rd 方的东西在某种程度上很便宜。或者以某种方式支持另一个。 IOW 政治。
我同意在某些情况下确实如此，但这是一个特殊情况。为什么雅虎聘请 Douglas Crockford 来开发 YUI？做出某些决定的原因可能不仅仅是企业竞争力。
ReactJS 比市场上的其他任何东西都好（今天，现在），并因此占据了市场份额。毕竟，它们实际上太好了，无法使用其他框架。

【解决方案7】：

它们需要如此高的性能和效率，以至于 jQuery 无法满足。他们需要一个只适合他们需求的 API，没有额外的未使用代码或功能。

【讨论】：

这可能是一个很好的理由。但不要告诉我 facebook 的表现很好 xD
@yes123 - 你不知道 FB 工程师面临什么样的条件。
@jared: 不，我从来没有为 fb 工作过
@yes123 - 将您对 FB 性能的独特体验与随时在请求中轻松排在前 3 位的网站的需求/要求进行比较是徒劳的。我并不是说他们做出的决定总是有用或明智的，但要归功于他们：该网站的运行频率更高。
@jared：实际上它遭受了很多停机时间/缓慢的影响。如果我有 20 亿/年，我可以购买支持 fb 的相同服务器场

【解决方案8】：

@yes123：当您建立一个最终服务于地球一半的网站时，您将开始遇到任何类型的框架最终都会强加的墙壁。当您制作自己的自定义框架、数据库查询语言等时，您拥有更多的控制权，并且可以真正着手优化一个必须每秒处理大量请求的网站。

当然还有其他考虑因素，如果你所做的一切都是开源的并且是公开的，那么错误和固有的弱点也是如此。并非每个人都如此无私地向框架或库的原始作者提交修复；有些人会用它来剥削。如果您的源本质上是封闭的和专有的，那么恶意用户的任务就会变得更加棘手。

无论如何，这对于 StackOverflow 来说并不是一个真正的问题......

【讨论】：

@yes123：那太棒了，但具体看 SO 的常见问题解答，这个问题并不真正属于问题的范畴。
这让我感到畏缩。 JavaScript 几乎没有什么可利用的，因为它没有安全性！它已经在您自己的浏览器中运行，您可以随意篡改代码，无论是否开源，代码对您完全可见。而你却反过来了：默默无闻的安全永远不会奏效，而开源代码通常更安全，因为代码库是已知的。
@Ricardo Tomasi：我的整个回答是否让您感到畏缩，或者只是在提到与安全相关的开源软件时导致这种下意识反应的部分？ “默默无闻的安全”本身显然不是真正的安全，它是人们希望成为多层系统的另一层。
只是第二部分，“如果你所做的一切都是开源和公开的，那么错误和固有的弱点也是如此”。那是一种力量。我曾多次从“害怕”使用 jQuery 的客户那里看到这个论点，因为它是开源的：/ 相反，他们希望在一周内获得一个全新/重写的库，这显然会变得更慢且更麻烦。