摄影：Krzysztof Grech

我一直很难在网上找到这方面的参考资料，但今年在描述这里概述的方法时多次听到这个名字。据我所知，“组件群岛”模式是由Etsy的前端架构师Katie Sylor-Miller在2019年的一次会议上创造的。

“Islands”架构的一般思想看似简单：在服务器上呈现 HTML 页面，并在高度动态的区域周围注入占位符或插槽。这些占位符/槽包含来自其相应小部件的服务器呈现的 HTML 输出。它们表示可以在客户端上“水合”成小型自包含小部件的区域，重用其服务器呈现的初始HTML。

您可以将其视为包含多个单独的嵌入式应用程序的静态 HTML 文档：

乍一看，这似乎类似于“微前端”。这两种方法都分享了将应用程序分解为独立单元的想法，但是“微前端”通常并不意味着这些单元的组成是使用HTML实现的。

与“岛屿”方法更接近的类似物是渐进式增强，我们基本上添加了SSR水合作用和一致的隐喻，以增加页面区域的交互性。在传统的渐进式增强中，我们可能会有一个在页面中查找图像轮播并在其上实例化jQuery插件的函数。相反，该图像轮播将在服务器上呈现，并为它发出一个专用的，该轮播加载图像轮播实现并就地将其升级为交互式。<script><script>

事实证明，与典型的单页应用程序体系结构相比，此处描述的一组方法有许多好处。

免费“渐进式补水”

我吹捧了React，Angular，Preact和Vue等框架的渐进式水合作用技术的性能优势。使用这些架构，页面上的各个小部件会随着时间的推移而加载和初始化。这可以通过 requestIdleCallback 使用简单的调度方法完成，也可以考虑其他因素，如视口可见性、交互可能性、产品价值等。

与渐进式水合类似，使用孤岛体系结构呈现页面会导致页面的较重动态部分不仅逐步初始化，而且单独初始化。这意味着页面的各个区域将变得具有交互性，而无需先加载页面上的任何其他内容。

与渐进式水合作用不同，围绕岛屿建筑进行构建的方法不需要自上而下的渲染。这是一个明显的优势，因为没有必须在其后代之前初始化的外部“根”组件。页面的每个部分都是一个隔离的单元，一个单元中的性能问题不会影响其他单元。

SEO和UX不是一个权衡

单页应用程序使用的SSR的现状是，由于SEO的原因，它经常被引用为必需品。但是，SSR实际上会对用户体验产生净负面影响 - 访问者只能等待页面的实际功能到达，同时盯着该页面令人沮丧的虚假版本。

许多应用程序还存在无声 SSR 性能缺陷，而没有意识到这一点。在虚拟 DOM 库中，很容易（并且很常见）意外构造一种情况，即第一个呈现会破坏服务器呈现的 HTML DOM，然后从头开始（通常是同步的）再次重新创建它。这是一些常见误解的结果，这些误解可能源于文档给出了理想化的水合作用观点，同时忽略了棘手的警告和脚枪。

即使在SSR水合作用按设计发挥作用的情况下，现状也有很多不足之处。在页面加载期间执行的JavaScript工作量仍然比可能被认为是“有效”的工作量高出许多数量级。

摄影：Dave Hoefler

在“孤岛”模型中，服务器渲染不是旨在改善SEO或UX的附加优化。相反，它是如何将页面传递到浏览器的基本部分。响应导航而返回的 HTML 包含用户请求的内容的有意义且可立即呈现的表示形式。

该 HTML 的某些部分可能缺少其客户端交互性，但文档至少应包含最重要的内容。例如：新闻页面的 HTML 将包含文章正文，产品页面将包含该产品的描述。

所有其他内容都是次要的，并且将其包含在HTML中成为产品决策。这些信息对访问页面的用户有多重要？该小部件对商业模式有多重要？与收入直接相关的“立即购买”按钮应轻松优先于与信息收集相关的网站反馈调查按钮。

更好的可访问性和可发现性

使用标准 HTML 链接进行导航的网站更易于辅助技术和 Web 爬网程序使用。无论链接或表单是否被 JavaScript 截获并重新路由到客户端逻辑，这都是正确的，因为基本假设仍然正确：单击链接导航到给定页面。

有趣的是，想想你被发送“链接”的次数，指向发件人认为他们正在查看的页面，只是意识到链接不包含任何必要的信息：

构建基于页面的应用程序并不能完全防止这些类型的奇怪体验，它只会使决策更加直接。它使默认结果成为可访问的结果。

归根结底，发布一个需要更少代码来做某事的架构是你未来的自己（或同事）会感谢你的长期利益。采用这样的模型可能-很可能，甚至-需要更多的前期设计思维。很少有包含电池的选项可用于将应用程序分解为独立可交付的小部件。谁知道呢，也许我们可以解决这个问题。

摄影：Max Hermansson