共计 3329 个字符，预计需要花费 9 分钟才能阅读完成。
原文题目：Island Architecture
原文：Island Architecture | Maina Wycliffe Blog
作者：Maina Wycliffe
建设一个网站有不同的办法，其中之一便是多页应用程序 (MPA)，它大概在十年前就过期了，当初又从新流行起来。MPA 曾经被 Angular 和 React 以及其余古代框架所遍及的单页利用(SPA) 办法所取代。
因为应用软件迭代趋势的运作形式，办法 / 工具很容易过期。这并不是因为它的效率低，而是因为开发人员不再应用它们来反对其余货色。这就是多页利用 (MPA) 所产生的事件，开发人员开始采纳风行的 Web 框架，如 Angular、React、Vue 等。这导致了 SPA 应用的回升，因为框架变得越来越风行。
因为 SPA 的工作形式，导致咱们发送到浏览器的 Javascript 数量减少了。也就是说，如果没有 React 来治理状态和渲染，你就不能有一个 React Web 应用程序。SPA 应用 Javascript 来出现要在浏览器中显示的 HTML。在许多状况下，这是可取的，例如，在 Facebook 或 YouTube 等网络应用程序中，治理状态至关重要。但在其余状况下，这没有意义，例如博客、集体作品集等。
SSR Server-Side Rendering 服务端渲染
当应用 Angular 或 React 等 SPA 框架时，服务器做的很少，所有的渲染都是在客户端实现的，也就是所谓的客户端渲染。要查看内容，你首先须要下载框架的运行态(JS 须要撑持你的 web 应用程序)，还须要一个渲染内容的环境，也就是浏览器。
这有一些毛病，值得注意的是它在屏幕上显示一些货色的速度很慢，这对低端设施和较慢的网络情况和搜索引擎优化的影响更糟——机器人和爬虫通常无奈渲染这些页面，也不能通过解析内容来获取显示后果。
咱们有两个规范的解决方案来解决上述问题: 服务器端渲染 (SSR) 和构建时渲染(SSG)。SSG 相似于 SSR，但在构建时，不须要在服务器上对每个申请进行渲染。SSG 通常用于内容不那么动静的网站。这两种解决方案的问题在于，它们不能解决 SPA 的问题，而是推延它。
如果你想要领有任何模式的交互性，比方关上和敞开网页利用上的导航栏，你就须要从 SSG 或 SSR 中为渲染的利用润色。这其实是疏导你正在应用的框架的过程，从服务器传输状态，以便框架能够接管。这通常产生在绘制第一个内容之后（从服务器出现服务器端出现的 HTML 之后），但在 Web 利用中的交互性之前。
这意味着必须下载和解析框架所需的 JS，并且用户必须期待所有这些事件产生后能力与您的 Web 应用程序进行交互。这意味着即便在咱们不须要交互性的页面上，即“对于咱们”页面、条款等等，依然须要执行所有这些下载和解析操作，这有点没有必要。
岛屿 Islands
这就是孤岛架构（Islands Architecture）的用武之地了。设想一下：你能够应用纯 HTML 和 CSS 为所有动态内容创立 Web 应用程序，而后增加动静内容或交互区域（孤岛），这些区域能够应用框架来增加交互性，并且这些区域能够应用任何框架，运行态框架只有在应用到它的页面上才会被下载，而不是在网站的初始加载中。
Astro（我的网站是用 Astro 构建的）、Marko 和最近的 Qwik 等 Web 框架都在实现这种架构办法。以 Astro 为例，Astro 组件应用 JSX 的某些变体，但没有客户端状态，因而没有运行态。
Astro 框架
Astro 应用 JS 抉择退出的概念，这意味着在默认状况下，不会生成 Javascript，除非你被动通知 Astro 须要蕴含这些 Javascript。如下所示:
<script>
document.getElementById("menuToggle").addEventListener("click", () => {const collapsibleMenu = document.getElementById("collapsibleMenu");
collapsibleMenu.classList.toggle("navbar-menu-show");
collapsibleMenu.classList.toggle("navbar-menu-hidden");
});
</script>以上 JS 代码片段来切换挪动菜单的关上和敞开
Astro 组件不能被 hydrate（注水），因为它们是 HTML 模板组件，任何 Javascript 脚本都须要通过如上办法或通过 React、SolidJS 等框架蕴含其在内。
第二种抉择是引入你应用的框架，例如 React, Preact, Lit, slvelte, Vue 等，来创立在你的 web 利用中增加交互区域 (岛) 的组件。
// index.astro file
---
import ReactComponent from "./ReactComponent"
---
<ReactComponent />你也能够管制必要部位的补水工夫。这是通过批示 Astro 何时进行注水作用来实现的。例如，您可能心愿一个岛在装载时或仅当它可见时才加水。有几个指令能够帮忙您实现这一点，您能够在这里理解更多。
// index.astro file
import ReactComponent from "./ReactComponent"
<ReactComponent client:visible />Marko 和 Qwik 框架
尽管我不是 Marko 或 Qwik（社区新秀）的专家，但如果您有趣味理解更多，我将在上面链接了其余资源。与 Astro 相比，Marko 和 Qwik 将岛屿的概念更进一步。
Marko 是一个 MPA 框架，它的 Island 架构更聪慧一些，因为它会主动决定加载一个 Island 所需的 JS，尽可能地提早它，容许更高效的 Island。这与 Astro 目前的办法不同，后者依赖于开发人员通知 Astro 何时进行注水。Astro 仍处于预公布阶段，兴许将来这种状况会有所扭转。
Marko 绝对于 Astro 的另一个要害劣势是，Marko 能够决定岛上有什么 or 岛上没有什么。这意味着仅显示动态内容的组件（如页脚、页眉等）不会成为孤岛，而表单和其余具备动静内容的丰盛组件将成为能够水化的孤岛。
另一方面，Qwik 将其带到组件级别，合成了注水的形式，以便仅在须要时进行注水。这是通过踊跃地将网站的 JavaScript 合成为多个块，设置全局事件侦听器并将趣味点间接序列化为 HTML 来实现的。对于每个不同的用户交互，Qwik 领有仅加载执行操作所需的代码所需的所有，仅此而已。
作为回报，这将导致代码块更小，从而可能更快地加载、解析和加载用户须要的内容。这就是所谓的渐进式注水，这超出了本文的探讨范畴，心愿我能很快就此进行探讨。
总结
本文着眼于岛屿架构，它们存在的起因以及以后利用它们的框架。在接下来的系列文章中，我想更深刻地钻研下面提到的框架 —— Astro，Marko 和 Qwik，以及其余框架，如 Svelte，Angular 和 React，以及它们在外部之间的区别。
参考起源
- Why Progressive Hydration is Harder than You Think
- From Static to Interactive: Why Resumability is the Best Alternative to Hydration
- JavaScript vs. JavaScript. Fight!
- Why Efficient Hydration in JavaScript Frameworks is so Challenging
- Resumable JavaScript with Qwik
- Conquering JavaScript Hydration Event delegation is the key to not running over the component… Apr 15
- State of JavaScript 2021: Framework Reflections
- A first look at Qwik – the HTML first framework WRITTEN BYMIŠKO HEVERY JULY 2, 2021
举荐扩大浏览（译者）
- Islands 架构原理和实际 – 掘金
- 从 Islands Architecture 看前端有多卷 – 掘金
