包括本地与远程 javascript 库答案

【问题标题】：Including local vs. remote javascript libraries包括本地与远程 javascript 库
【发布时间】：2012-11-20 06:41:59
【问题描述】：

我正在使用 jsSHA 1.3.1，我 downloaded here 并在我的本地主机上用于学习项目。它给出的结果与我通过引用遥控器得到的副本略有不同，如下所示：

<script src="https://raw.github.com/Caligatio/jsSHA/master/src/sha1.js"></script>

感谢@Andreas here 的出色回答，现在远程复制对我来说效果很好。

但这给我留下了一个新问题：包含副本与引用远程 js 库的理由是什么？是否像“供应”库一样，将我的应用与代码中的后续更改隔离开来？

【问题讨论】：

下载链接最后一次更新是在 4 个月前，而存储库在那段时间里有很多活动stackoverflow.com/questions/5502540/…
如果你要盗链 GitHub，你应该先尝试 gh-pages 分支中的文件，它们很可能是最新的稳定版本。在这种情况下，它是caligatio.github.com/jsSHA/sha.js
在上一个问题中提到问题会使问题不太清楚。也许您可以对其进行编辑以使 new 问题更加突出？（并不是说您不应该链接到旧问题，但也许您可以先说明新问题，然后为任何感兴趣的人提供旧问题的链接。）干杯！我喜欢这个问题，并愿意投票，但它需要一点 OP 的关注 :-)
现在我想了想，一旦我接受了另一个问题的建议，它就解决了。我将删除整个最后一段。谢谢你的建议。

标签： javascript sha

【解决方案1】：

这取决于开发人员是否对您“热链接”到 JS 库感到满意。

关于您发布的具体网址，

https://raw.github.com/Caligatio/jsSHA/master/src/sha1.js

我会谨慎引用它。它是其源代码的主分支，它们可能随时包含重大更改。他们甚至可能决定移动和重组他们的代码库，在这种情况下，您的应用程序将中断，因为上面的 URL 将导致 404。

更好的解决方案确实是引用库的特定版本。这可确保您的应用程序以预期和已知的方式运行，并将继续运行，就 jsSHA 库而言。

有几种方法可以做到这一点。您可以引用明确指定版本的特定固定 URL

http://crypto-js.googlecode.com/svn/tags/3.0.2/build/rollups/hmac-sha1.js

因为它被标记为 (3.0.2)，所以你更安全一些，但你仍然引用源代码控制。如果存在 CDN，这确实应该通过 CDN 完成。我不相信 googlecode.com URL 是 CDN URL（我可能是错的）。使用适当的 CDN 或外部链接来引用 JS 库当然是一种常见的做法，您可以看到 example of this on the JQuery page，但这通常是作为页面性能增强的一部分。 CDN 针对用户的地理位置进行了优化，因此可以更快地提供对 CDN（与主服务器相反）上任何内容的引用。它具有用户体验优势。如果页面加载时间对您的用户群很重要，这很有用。

另一种选择，也是最安全的方法，是将 JS 库的副本保存在您自己的源代码管理中，并使用您自己的基础架构引用它。它与您同在，它是一个固定版本，如果发生某些变化（例如重组、网站关闭等），也不会让人感到意外。

【讨论】：

【解决方案2】：

如果您的应用程序在 WWW 上可用，您应该考虑使用众所周知的外部 URL。

<script type="text/javascript"
   src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js">
</script>

以下示例从 google 的服务器获取 jquery 1.8.0 的缩小版本。

这种方法获得的好处来自于缓存：
您不希望潜在用户第一次访问您的网站时既缓慢又令人失望。如果您的第一次访问者访问了我的网站，该网站使用了 jQuery 的这个 URL，她的浏览器可能已经缓存了它，所以它不需要加载它。
使用不可变的版本化资源（jquery/1.8.0 而不是 jquery/current 之类的资源）既可以帮助开发人员不必跟踪其生产代码中的重大更改，又可以确保可以缓存这些资源。
如果必须下载资源并且 URL 托管在 CDN 上，您可能会获得较低的延迟，因为资源可能会从更靠近用户网络的服务器加载。示例中的 URL 托管在作为 CDN 的 Google Hosted Libraries 上。请参阅https://developers.google.com/speed/libraries/devguide 了解更多信息。
在此类讨论中经常看到的另一个论点是，当必须下载资源时，如果资源不在您自己的服务器上以及您的页面包含的另外 10 个资源，您将能够获得更好的客户端资源加载并行性因为浏览器限制自己最多只能从同一服务器加载少量（现代浏览器中大约 6 个）资源。
如果您的互联网范围内的网络应用程序对安全至关重要，那么您必须尽可能安全地控制它（并且静态不可变或几乎不可变的资源相对容易安全地管理）。
如果我的银行通过 HTTPS 运行的电子银行应用程序依赖谷歌的 HTTP 服务器进行服务，那么它既会授予谷歌对其电子银行应用程序客户端部分的权限，又会消除几乎所有的好处与其服务器的 HTTPS 连接。流氓客户端脚本无法做的事情很少......
如果您的应用程序是在本地访问的，您可能应该将其包含在您的应用程序中，以兼顾性能（无论是就延迟还是带宽而言，访问您的服务器应该比访问远程服务器更快）和可靠性原因（您不依赖于外部互联网连接和远程服务器正在启动和运行）。

【讨论】：

缺少这些 > 在第一个脚本标记处应该是