使用iFrame进行SPA？

Question

我们公司正在重新设计一个网络服务作为SPA。我使用jquery + css + html设计了前端的粗略版本。但我的一个功能是Tabs界面。它最多可以有8个标签，这似乎会减慢整个网络应用程序的速度。每个选项卡都包含一个类似于100多行的表，除了少数几个具有更复杂ui的选项卡。 现在，我们已经分配了另一家公司，通过后端修改完成服务并应用新的ui。该公司坚持使用iframe使多个开发人员能够更轻松地同时协同工作并提高性能。 老实说，我觉得这没什么意义，特别是考虑到每个标签的DOM结构都不复杂也不长。但事实是iframe是我不喜欢的东西，没有明显的理由。所以我想知道人们是否可以建议为什么不使用它，甚至为什么我应该同意它

Answer 1

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

答案非常简单，使用网络组件。

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

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

现在针对您的问题，您可以将任何选项卡作为组件进行操作，并且仅当用户移动到此选项卡时才进行渲染。因此，您不必渲染所有选项卡，只需渲染一个。

查看polymer - 一个用于web组件的糖语法库。

您还可以查看其他框架的角度，反应......

Answer 2

这是一个仍然很重要的问题，所以我将在4年后回答。 SPA可能很快就变得单一，特别是对于企业应用程序而言，其构建时间慢，开发人员经验差，框架锁定以及协调频繁稳定发布的难度越来越大。这是一个或多或少已被公认的问题，该解决方案受到了微前端的关注。

这里是thoughtful article on Martin Fowler，位于微型前端。您会注意到，iframe是为微型前端创建外壳的第二个“最佳”解决方案，尽管事实上没有人愿意使用它们，因为它们既老式又不酷。它们允许框架之间的高度隔离（单独的文档，单独的合并范围）。它们简单易懂。 IFrames源自框架集，该框架集是在1996年的Netscape 2发行版中发布的。Web纯粹主义者感到恐惧，但它们会立即使允许的内容窗格独立于导航滚动，从而为我们提供了左侧的导航面板。这样就可以了，框架是永久性的不时髦但坚固且有用的解决方案。