关于前端:从-Islands-Architecture-看前端有多卷

大家好，我卡颂。

最近，Remix团队的火暴老哥 Ryan Florence 一连怼了好几个友商框架，比方：

• 喷 SolidStart 抄Remix的文档

• 怼 Next.js 抄Remix的 API 设计

• 吐槽 Astro、Qwik 没有什么陈腐理念

当然，这些推文收回不到一天就被老哥删了 🤫。

咱们明天不聊以上这些事儿的对错。

我想问问 不常关注前端新轮子倒退的同学，此时你们的心田流动是不是：

这 TM 都是些啥框架？我咋一个都不意识？

明天，咱们从被 Ryan 吐槽的 Astro 的理念 —— Islands Architecture登程，来看看前端到底有多卷。

欢送退出人类高质量前端框架群，带飞

Islands Architecture 是什么

Islands Architecture（孤岛架构）的概念最后是由 Etsy 的前端架构师 Katie Sylor-Miller 在 2019 年提出，并由 Preact 作者 Jason Miller 在 islands-architecture 一文中推广。

这是一套基于 SSR（服务端渲染）的架构。要理解他的特点，咱们须要先理解传统SSR 的缺点。

在传统 SSR 中，首屏渲染时，服务端会向浏览器输入 HTML 构造。

当浏览器渲染 HTML 后，再执行前端框架的初始化逻辑，为 HTML 构造绑定事件，这一步叫hydrate（注水）。

当 hydrate 实现后，页面能力响应用户交互。

也就是说，只有当整个页面所有组件 hydrate 实现后，页面中任一组件能力响应用户交互。

Chrome LightHouse跑分中的 TTI（Time to Interactive，可交互工夫）指标用于掂量 页面变得齐全可交互所需的工夫。

传统 SSR 架构的页面随着利用体积变大，TTI指标会继续走高。

孤岛架构 的目标就是为了优化 SSR 架构下 TTI 指标的问题。

在 孤岛架构 架构下，组件分为：

• 交互组件
• 首屏不可交互组件

比方在如下页面构造中：

• 首屏不可交互组件 包含Content、Advertisement、Footer（红色局部）
• 交互组件 包含Header、Sliderbar、Image Carousel（黑白局部）

首屏不可交互组件 会像传统 SSR 一样向浏览器输入 HTML，而 交互组件 会在浏览器异步、并发渲染。

交互组件 就像 HTML 陆地中的孤岛，因而得名 孤岛架构。

孤岛架构 能够让 交互优先级较高的组件 优先变得可交互，剩下的低优组件再缓缓hydrate。

如此，在页面 hydrate 实现前，重要的组件曾经可交互了，借此就能升高 TTI 指标。

孤岛架构 的现实意义在哪呢？比方，对于一个电商网站，显然 立即购买按钮 的可交互性优先级高于 反馈按钮 的可交互性。

SSR让用户可能更早看到页面，孤岛架构 让页面中重要的局部（立即购买按钮）能够更早被点击。这背地，就是更高的购买率，更多的钱～～～

实现 Islands Architecture 的框架

在以后，实现 孤岛架构 的全栈框架次要是 Astro 与Qwik。

Astro

Astro的特点是：作为全栈框架，次要把控整体架构，对实现具体业务所需前端框架没有要求。

也就是说，开发者能够在 Astro 中应用 React、Vue、Preact、Svelte 等框架实现具体业务逻辑，甚至是在一个 .astro 组件中混用其余框架的组件。

比方，在上面例子中 .astro 组件中引入了 React、Vue、Svelte 三款框架的组件：

Qwik

Qwik的作者是 builder.io 的CTO miško hevery（同时也是 Angular/AngularJS 的发明者）。

这款框架的特点是：超细粒度的 孤岛架构，且粒度是开发者可控的。

对于 Astro， 孤岛架构 实用的对象是组件。而在 Qwik 中，孤岛架构 最细的粒度是 组件中的某个办法。

举个例子，上面是 HelloWorld 组件（能够发现，Qwik采纳相似 React 的语法）：

对应页面渲染成果：

关上浏览器 Network 面板，这个页面会有多少 JS 申请呢？

因为这是个动态的组件，没有逻辑，所以答案是：没有 JS 申请。

再来看看经典的计数器 Counter 组件，相比 HelloWorld，减少了 点击按钮状态变动的逻辑，代码如下：

对应页面渲染成果：

关上浏览器 Network 面板，这个页面会有多少 JS 申请呢？

答案还是：没有 JS 申请。

留神这两个组件的代码中，定义组件应用的是 component$，有个$ 符号。

在 Counter 中，onClick$回调也有个 $ 符号。

在 Qwik 中，后缀带 $ 的函数都是 懒加载 的。

孤岛架构 的粒度有多细，就取决于 $ 定义的多细。

比方在 Counter 中，onClick$带 $ 后缀，那么点击回调是懒加载的，所以首屏渲染不会蕴含 点击后的逻辑 对应的 JS 代码。

在点击按钮后，会发动 2 个 JS 申请，第一个申请返回的是 点击后的逻辑：

第 2 个 JS 申请返回的是 组件从新 render 的逻辑：

这两段代码执行后，Counter变为 1。

审查元素会发现，点击前，button on:click属性中保留了 逻辑所在的地址：

点击后，会从对应地址下载 JS 代码，执行对应逻辑。

React

为什么文章结尾火暴老哥吐槽 Astro、Qwik 没有什么陈腐理念呢，这是因为 React 很早就在朝着 孤岛架构 的理念倒退了。

在 React 中，这套理念被称为 Selective Hydration。

具体来说，在 SSR 场景下，被 Suspense 组件包裹的组件会作为 孤岛架构 下的 交互组件。

前端有多卷

尽管 孤岛架构 下的全栈框架有泛滥益处（首屏渲染快、TTI短），但并不是万能的。

他比拟适宜 对首屏渲染速度、TTI 要求高，但整体页面交互不简单 的场景，比方：

• 电商页面
• 博客
• 文档

对于 重交互性 的Web利用（比方 后盾管理系统 、 社区 ），更适宜传统的SSR 计划（比方 Next.js）或CSR 计划（间接应用前端框架）。

可见，孤岛架构 的利用场景并不大，但他的实现难度却比 CSR 或传统 SSR 高得多。

大部分开发者，究其毕生可能都不会用到 孤岛架构。

就是这么小的细分畛域，都涌现了这么多竞争对手。

前端，真是太卷了 ……