我们公司正在将 Web 服务重新设计为 SPA。我使用 jquery+css+html 设计了粗略的前端版本。但我的功能之一是选项卡界面。它最多可以有 8 个选项卡，而且它似乎会减慢整个网络应用程序的速度。每个选项卡都包含一个表格，其中包含 100 多行，但少数选项卡具有更复杂的用户界面。 现在，我们有另一家公司被指派完成后端修改的服务并应用新的用户界面。这家公司坚持使用 iframe 是为了让多个开发人员更容易同时协同工作，同时也提高了性能。 老实说，我认为这没有什么意义，尤其是考虑到每个选项卡的 DOM 结构既不复杂也不长。但事实是 iframe 是我不喜欢的东西，没有明显的原因。所以我想知道人们是否可以建议为什么不使用它，甚至为什么我应该同意它
这是一个仍然相关的问题，所以我晚了 4 年才给出答案。 SPA 会很快变得单一，尤其是对于企业应用程序而言，构建时间缓慢、开发人员体验差、框架锁定以及协调频繁稳定发布的难度越来越大。这是一个或多或少公认的问题，解决方案在微前端的旗帜下。
这里有一篇关于 Martin Fowler 的深思熟虑的文章，关于微前端。您会注意到 Iframes 是为您的微前端创建外壳的第二个“最佳”解决方案，尽管事实上没有人愿意使用它们，因为它们过时且不酷。它们允许框架之间有很好的隔离度（单独的文档，单独的范围）。它们简单易懂。 IFrame 源自 1996 年与 Netscape 2 一起发布的框架集。Web 纯粹主义者感到震惊，但他们立即允许内容窗格独立于导航滚动，从而为我们提供了左侧导航面板。所以你有它，框架是一个永远不流行但强大且有用的解决方案。
我认为为此目的使用 iframe 是个坏主意。 iframe 很慢，主框架之间的事件和信息传递到 iframe 不是那么容易。
答案很简单，使用web-components。
这是多个开发人员同时一起工作的解决方案。每个开发人员在单个或多个 Web 组件上工作，并且当您可以重用和共享组件时，还可以加快开发速度。
如果你加载组件并在正确的时间渲染它们，你可以获得非常好的性能，比 iframe 更好。
现在解决你的问题，你可以将任何选项卡作为一个组件来做，只有当用户移动到这个选项卡时才会呈现它。因此，您不必渲染所有选项卡，而只需渲染一个。
看看 polymer - 一个库，它是网络组件的糖语法。
你也可以看看其他框架 angular,react...
Iframes 可以成为微前端管理的最佳和最快的答案。 他们对风格和资源都有很好的隔离。它们允许独立部署并简化拆分布局。
但只想指出一些缺点。
选择它只是关于什么最适合您的需求。