54

我必须开发一个第三方网站将使用的小部件。这不是要部署在社交网站中的应用程序。我可以给站点人员一个链接，用作 iframe 的 src，或者我可以将其开发为 JavaScript 请求。

有人可以告诉我这两种方法（IFrame 与 JS）之间的权衡吗？

4

6 回答 6

31

我正在搜索同样的问题，发现这篇有趣的文章： http:
//prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/

小部件是可以轻松添加到任何网页的小型 Web 应用程序。它们有时被称为小工具，并广泛用于越来越多的网页、博客、社交网站、个性化主页，如 iGoogle、我的雅虎、netvibes 等。在这个博客中，我使用了几个小部件，比如右侧的 RSS 计数器它显示了有多少用户订阅了这个博客（别担心，它会增长，这是一个新博客 ;-) ）。从某种意义上说，小部件很棒，因为它们是可重复使用的小型功能，即使是非程序员也可以利用它来丰富他们的网站。

我已经编写了几个这样的小部件，包括可以嵌入到任何网站的“原始”小部件，以及结构化的 iGoogle 小工具、worpress*、打字板和博客小部件，因此我很乐意分享我的经验。

作为小部件作者，对于在客户端运行的小部件（简单的可嵌入 HTML 代码），您可以选择在 iframe 中编写小部件，或者简单地将页面内联并使其成为托管页面 dom 的一部分。这篇文章的其余部分讨论了这两种方法的优缺点。

它在技术上是如何完成的？如何使用 iframe 或如何实现内联小部件？

iframe 更容易实现。以下示例呈现一个简单的 iframe 小部件：http://my-great-widget.com/widgwt' width="100" height="100" frameborder='0'>

frameborder='0' 用于确保 ifrmae 没有边框，使其在页面上看起来更自然。http://my-great-widget.com/widget负责将 小部件内容作为完整的 HTML 页面提供。

内联小工具可能如下所示：

function createMyWidgetHtml() { return "Hello world of widgets"; } document.getElementById('myWidget').innerHTML = createMyWidgetHtml(); 如您所见，函数 createMyWidgetHtml() 它负责创建实际的小部件内容，并且不一定要与服务器对话才能做到这一点。在 iframe 示例中，必须有一个服务器。在内联示例中，不需要服务器，但如果需要，可以从服务器获取数据，这实际上是一种非常常见的情况，小部件通常会调用服务器端代码。使用内联方法服务器端代码通过按需 javascript 调用。

因此，总而言之，在 iframe 案例中，我们只需放置一个 iframe HTML 代码并将 iframe 的源指向一个服务器位置，该服务器位置实际上为小部件的内容提供服务。在内联案例中，我们使用 javascript 在本地创建内容。您当然可以将 iframe 与 javascript 的使用以及内联方法与服务器端调用的使用结合起来，您不受此限制，但路径开始不同。

那么有什么大不了的呢？有什么不同？有几个重要的区别，所以这里开始这篇文章有趣的部分。

安全。iFrame 小部件更安全。

小工具会带来哪些风险，谁实际上处于危险之中？该网站的用户和该网站的声誉处于危险之中。

对于内联小工具，浏览器认为小工具代码代码的来源来自托管站点。假设您正在浏览您最喜欢的邮件应用程序http://my-wonderful-email.com，并且此邮件应用程序安装了一个小部件，该小部件显示来自 http://great-clock-widgets.com/的时钟. 如果该小部件被实现为内联小部件，则浏览器认为该小部件的代码源自 my-wonderful-email.com 而不是来自 great-clock-widgets.com，因此它将让小部件的代码最终访问 cookie由 my-wonderful-email.com 拥有，小部件的邪恶作者将窃取您的电子邮件。重要的是要意识到浏览器并不关心 javascript 文件的托管位置。只要代码在同一个框架上运行，浏览器就会将所有代码视为框架域的起源。因此，作为用户，您会因失去对电子邮件帐户的控制而受到伤害，而 my-wonderful-email 会因失去声誉而受到伤害。

如果在 iframe 中实现了相同的时钟并且 iframe 源与页面源不同（这是常见的情况，例如页面源是 my-wonderful-email.com 而小工具源是 great-clock-widgets .com) 那么浏览器将不允许时钟小部件访问页面 cookie，也不允许访问托管文档的任何其他部分，包括主机页面 dom。这样更安全。事实上，像 iGoogle 这样的个人主页甚至不允许内嵌小工具，只允许使用 iframe 小工具。（仅在极少数情况下允许使用内嵌小工具，只有在经过 iGoogle 团队彻底检查以确保它们没有恶意之后）

总而言之，iframe 小部件更安全。但是，它们的功能也受到更多限制。接下来，我们将讨论您在功能上失去了什么。

外观 在外观和感觉的战斗中，内联小工具（通常是**）获胜。它们的好处是可以使它们看起来是页面的一部分。它们可以从页面继承 CSS 样式，包括字体、颜色、文本大小等。Iframe、OTHO 必须从头开始定义它们的 CSS，因此它们很难很好地融入页面。

但更重要的是 iframe 必须声明它们的大小。在向页面添加 iframe 时，您必须包含 width 和 height 属性，如果不这样做，浏览器将使用一些默认设置。现在，如果您的小部件是一个时钟小部件，它很容易 b/c，您确切地知道您想要它的大小，但在许多情况下，您不提前知道您的小部件将占用多少空间。例如，如果您正在创作一个显示某种列表的小部件，并且您不知道该列表将有多长或每个项目将有多宽。通常在 HTML 中这没什么大不了的，因为 HTML 是一种基于声明的语言，所以你需要做的就是告诉浏览器你想显示什么，浏览器会为它找出一个合理的布局，但是对于 iframe，情况并非如此；使用 ifrmaes 浏览器要求您准确地告诉它 iframe 的大小是多少，它不会自己弄清楚。对于想要使用 iframe 的小部件作者来说，这是一个真正的问题——如果您需要太多空间，页面中就会出现空白，如果您指定的页面太少，页面中就会有滚动条，上帝禁止。

外观和感觉明智，内联获胜。但请注意，这实际上取决于您的小部件应用程序。如果您只想做一个时钟，那么您也可以使用 iframe。

服务器端与客户端 IFrmaes 要求您指定 src URL，因此在使用 iframe 实现小部件时，您必须具有服务器端代码。这对某些人来说可能是一个限制和头痛（拥有服务器、域名等、处理负载、支付网络账单等），但对其他人来说，这实际上是支持 iframe b/c 的一点，它让你完全编写你的服务器端技术中的小部件，因此您可以编写大量代码，实际上几乎所有代码都使用您最喜欢的服务器端技术，无论是 asp.net、django、ror、jsp、struts、perl 还是其他恐龙。在实现内联小工具时，您会发现自己越来越多地练习 JavaScript Ninja。

那么决策算法是什么？小部件作者：如果小部件可以实现为 iframe，则更喜欢 iframe，只是为了保护用户的安全和信任。如果一个小部件需要内联（并且媒体允许，例如不是 iGoogle 和朋友）使用内联但不敢利用用户的信任！

小部件安装程序：在您的博客中安装小部件时，您不会在小部件上看到“用户安全”功能区。您如何判断小部件是否安全？我可以建议两种选择：1）信任供应商 2）阅读代码。要么您信任小部件提供者并安装它，要么您花时间阅读它的代码并确定它是否值得信赖。现实情况是，大多数网站所有者不费心阅读代码，甚至没有意识到他们将用户置于风险之中，因此小部件提供商被盲目信任。在许多情况下，这不是问题，因为博客通常不会保存有关其读者的个人信息。我怀疑一旦很少有高调的漏洞利用，事情就会开始改变（我希望它永远不会发生）。

用户：Usres 被蒙在鼓里。就像网站所有者安装的小部件上没有“对用户安全”的功能区一样，也没有“使用安全”的网站，基本上用户被蒙在鼓里，不知道，即使他们有技术技能，无论是否他们使用的网站包含小部件，这些小部件是否内联以及它们是否是恶意的。尽管理论上训练有素的开发人员可以在浏览器中运行代码并将其电子邮件帐户丢失给黑客之前预先检查代码，但是这是不切实际的，并且不应期望大量用户会这样做。IMO 这是一个不幸的情况，我只希望攻击者不会找到利用它的方法，并毁灭网络上美妙的开放小部件文化。

快乐的小部件人！

  • 一些博客平台的小部件结构有些不同，有时它们可​​能同时具有功能相关的小部件和插件，但就这里的讨论而言，我将愚蠢地使用术语小部件来讨论“原始”类型由客户端javascript代码组成**虽然在大多数情况下您希望小部件从托管页面继承样式以使其看起来与其一致，但有时您实际上不希望小部件从页面继承样式，所以在这个案例 iFrames 让你从头开始你的 CSS。
于 2011-03-04T23:41:55.600 回答
13

为什么不两者都做？

我更喜欢为第三方网站提供如下脚本：

 <script type="text/javascript" src="urlToYourScript"></script>

您服务器上的文件如下所示：

document.writeln('<iframe src="pathToYourWidget" 
name="MagicIframe" width="300" height="600" align="left" scrolling="no" 
marginheight="0" marginwidth="0" frameborder="0"></iframe>');

更新：

使用指向服务器上 url 的 iframe 的一个缺点是，如果有人单击服务器上指向服务器的 url，则不会生成“真实”反向链接。

于 2012-12-15T19:09:52.623 回答
5

我敢肯定，许多开发人员/网站所有者会喜欢一种 Javascript 解决方案，他们可以根据自己的需要设置样式，而不是使用iframe. 如果我要包含来自第三方的组件，我宁愿通过 Javascript 来完成，因为我会有更多的控制权。

就易用性而言，两者在简单性方面相似，因此没有真正的权衡。

另一种想法是，确保您获得托管此域名的任何域的 SSL 证书，如果页面是通过 SSL 提供的，则相应地写出包含语句。如果您的网站所有者有使用 SSL 的理由，他们肯定会喜欢这一点，因为 Firefox 和其他浏览器会在提供混合安全/不安全内容的页面时抱怨。

于 2011-03-04T23:59:25.130 回答
3

如果小部件可以嵌入到 iframe 中，则托管站点的前端性能会更好，因为 iframe 不会阻止内容下载。但是，正如其他人所评论的那样，使用 iframe 还存在其他缺点。

如果您确实使用 javascript 实现，请在开发时考虑前端性能最佳实践。特别是，您应该查看Non blocking javascript loading。谷歌分析和其他 3rd 方小部件提供商支持这种加载方法。如果您可以在页面底部加载 javascript，这也会有所帮助。

于 2011-03-15T22:54:13.057 回答
2

很高兴知道它不会部署在社交网站中......只会留下网络的其余部分;-)

最有用的取决于您的小部件。IFrame 和 javascript 通常用于完全不同的目的，并且可以混合使用（即 iframe 中的 javascript，或创建 iframe 的 javascript）。

  • IFrame 有大小问题；如果它应该完全适合页面，您是否知道它在所有浏览器上呈现相同，数据不会溢出它的容器等？
  • IFrame 很简单。它们可以是简单的静态 HTML 页面。
  • 使用 IFrame 时，您可以非常清楚地公开您的小部件。
  • 但是话又说回来，为什么不让您的第三方网站在给定的 url 中简单地包含 HMTL？然后可以在需要时/如果需要，扩展 HTML 以包含 javascript。
  • 纯 Javascript 允许更大的灵活性，但代价是一些复杂性。
于 2009-02-11T06:59:31.070 回答
1

iframe 的一大优点：所有 CSS 和 JS 都与主机页面分离，因此您现有的 CSS 可以正常工作。（如果您希望主机站点对您的内容进行样式设置以适应，那当然是减号。）

iframe 的最大缺点：它们具有固定的宽度和高度，如果您的内容较大，则会出现滚动条。

于 2016-06-02T15:41:48.363 回答