使用 iFrame 进行 SPA？

Question

我们公司正在将 Web 服务重新设计为 SPA。我使用jquery+css+html设计了前端的粗略版本。但我的功能之一是选项卡界面。它最多可以有 8 个选项卡，而且似乎会减慢整个网络应用程序的速度。每个选项卡都包含一个包含 100 多行之类的表，但少数选项卡的用户界面稍微复杂一些。现在，我们已经指定另一家公司来完成后端修改并应用新用户界面的服务。该公司坚持使用 iframe 来让多个开发人员更容易同时合作并提高性能。老实说，我认为这没有什么意义，特别是考虑到每个选项卡的 DOM 结构既不复杂也不长。但事实是 iframe 是我无缘无故不喜欢的东西。所以我想知道人们是否可以建议为什么不使用它，甚至为什么我应该同意它

Answer 1

这是一个仍然相关的问题，所以我会晚四年才给出答案。SPA 很快就会变得单一，特别是对于企业应用程序而言，其构建时间缓慢、开发人员体验差、框架锁定以及协调频繁稳定版本的难度越来越大。这或多或少是一个公认的问题，解决方案位于微前端的旗帜下。

这是一篇关于 Martin Fowler 的关于微前端的深思熟虑的文章。您会注意到，Iframe 是为微前端创建外壳的第二个“最佳”解决方案，尽管事实上没有人愿意使用它们，因为它们过时且不酷。它们允许框架之间有良好程度的隔离（单独的文档、单独的范围）。它们很简单并且很好理解。IFrame 源自框架集，于 1996 年随 Netscape 2 发布。网络纯粹主义者感到震惊，但他们立即允许内容窗格独立于导航滚动，为我们提供了仍然存在的左侧导航面板。现在你知道了，镜框是一种永远不流行但坚固且有用的解决方案。

Answer 2

我认为为此目的使用 iframe 是一个坏主意。iframe 速度很慢，并且在主框架和 iframe 之间传递事件和信息并不那么容易。

答案很简单，使用web-components。

这是多个开发人员同时协作的解决方案。每个开发人员都处理单个或多个 Web 组件，并且当您可以重用和共享组件时，还可以加快开发速度。

如果您加载组件并在正确的时间渲染它们，您可以获得非常好的性能，比 iframe 更好。

现在解决您的问题，您可以将任何选项卡作为组件，并且仅当用户移动到该选项卡时才呈现它。因此，您不必渲染所有选项卡，而只需渲染一个选项卡。

看一下polymer——一个用于网络组件的糖语法库。

你还可以看看其他框架 Angular、React...