就在上周，Astro 團隊發(fā)布了 1.0 的正式版本。

從年初我就開始關(guān)注這個項目了，但當(dāng)時只是學(xué)習(xí)了一下倉庫的工程化搭建相關(guān)的東西 (changesets 自動發(fā)包之類)，并沒有深入了解它本身的功能。借著正式發(fā)版的機會，這幾天熟悉了一下 Astro 1.0，發(fā)現(xiàn)了很多有意思的地方，下文會分別從團隊背景、框架定位和核心優(yōu)勢幾個維度給大家展開介紹，最后也會推薦一些學(xué)習(xí)資料。

團隊背景

在正式介紹 Astro 之前，先給大家聊一聊相關(guān)的背景。Astro 的作者是 Fred K. Schott，沒錯，就是那個開發(fā) Snowpack 的老哥，可以說是 Unbundle 構(gòu)建工具的祖師爺：

但無奈的是 Vite 發(fā)展勢頭實在太猛，而 Snowpack 漸漸日薄西山，他本人也寫了文章發(fā)出下面的感慨:

?

文章鏈接: https://dev.to/fredkschott/5-more-things-i-learned-building-snowpack-to-20-000-stars-5dc9

大意就是 Snowpack 前途渺茫，用戶越來越少，感覺要做到頭了啦，而 Vite 發(fā)展的非常好，那后面開發(fā)的 Astro 就基于 Vite 來做吧?，F(xiàn)在連 Snowpack 的官網(wǎng)都表示棄坑了，主動給 Vite 引流:

當(dāng)然，除了 Snowpack，F(xiàn)red K. Schott 的團隊(叫Pika)還做了一件比較知名的產(chǎn)品: Skypack，即 NPM 包的 ESM CDN 服務(wù):

不幸的是，Skypack 也很長時間(一年多)沒有維護了，可以看出團隊也不再想繼續(xù)投入這個項目了，個人感覺主要有兩個原因:

• 競爭對手的強大。競品 esm.sh 一直在持續(xù)迭代且已經(jīng)得到了 Deno 的官方推薦。
• 方案落地困難。此類 ESM CDN 應(yīng)用到實際的業(yè)務(wù)項目中仍然有諸多的現(xiàn)實障礙，如請求數(shù)量多、不能 Tree Shaking、不能本地調(diào)試等等，要落地是一個比較難的問題。

在近些年的時間里，F(xiàn)red K. Schott 團隊一直將重心放在了新項目 Astro 上面，經(jīng)過 16 個月的打磨， Astro 在全球擁有了 30000 多個用戶，被 Google、Netlify 等大公司使用，Github 的 star 已經(jīng)達到 15k +。

值得一提的是，F(xiàn)red K. Schott? 為了這個項目專門成立了一個創(chuàng)業(yè)公司: The Astro Technology Company?，并且已經(jīng)融到了 700 萬美刀的種子輪投資，打算一直以開源的方式發(fā)展下去。相比于一些知名開源項目的贊助收入，如 Webpack[1] 22 w 刀/年、Babel[2]  30 w 刀/年，Astro 在經(jīng)濟方面有如魚得水的優(yōu)勢。

框架定位

接下來聊一聊 Astro 框架的定位，是像 Vue、React 這樣的底層渲染框架，還是像 Next.js 這種上層的研發(fā)框架？

這一點其實挺困擾初學(xué)者的，因為 Astro 既自創(chuàng)了類似于.vue、.jsx文件的 .astro 語法，又提供了像 Next.js 里面各種運行時的能力，比如約定式路由、構(gòu)建優(yōu)化、SSR 等等。

但實際上它給自己的定位非常清晰，即 content-focused 應(yīng)用開發(fā)框架，換句話說，就是重內(nèi)容、輕交互場景下的上層研發(fā)框架，比如大多數(shù)電商網(wǎng)站、文檔站、博客站、證券網(wǎng)站等等。

你可以將 Astro 理解為一個垂直場景下的Next.js，但它可以在它適用的領(lǐng)域里面可以勝過其它所有競品(如Next.js、Remix、Vuepress 等)，這是它能夠做起來的重要原因。接下來，我們就來看看 Astro 的優(yōu)勢在于哪些地方。

核心優(yōu)勢

Astro 的主要優(yōu)勢包括如下幾點:

• Islands 架構(gòu)，解決傳統(tǒng) SSR/SSG 框架的全量 hydration 問題，做到盡可能少的 Client 端 JS 的開銷，甚至是 0 JS。
• 學(xué)習(xí)成本低。.astro 語法和傳統(tǒng)的.jsx 和.vue 非常相似，對于新手前端來說也比較容易掌握。
• 使用靈活。對于頁面的開發(fā)，你既可以使用官方的.astro 語法，也同樣可以使用.md、.vue、.jsx 語法，也就是說，你可以自由選擇其它前端框架的語法來開發(fā)，甚至可以在一個項目中同時寫 Vue 組件和 React 組件！
• 構(gòu)建迅速。底層構(gòu)建體系基于 Vite 以及 Esbuild 實現(xiàn)，項目啟動速度非?？?。

Islands 架構(gòu)

在如上的幾個優(yōu)點中，我們來重點說一說 Astro 的 Islands 架構(gòu)，因為這是它高性能最主要的原因。

Islands 架構(gòu)模型早在 2019 年就被提出來了，并在 2011 年被 Preact 作者Json Miller 在Islnads Architecture[3] 一文中得到推廣。這個模型主要用于 SSR (也包括 SSG) 應(yīng)用，我們知道，在傳統(tǒng)的 SSR 應(yīng)用中，服務(wù)端會給瀏覽器響應(yīng)完整的 HTML 內(nèi)容，并在 HTML 中注入一段完整的 JS 腳本用于完成事件的綁定，也就是完成 hydration (注水) 的過程。當(dāng)注水的過程完成之后，頁面也才能真正地能夠進行交互。

那么當(dāng)應(yīng)用的體積逐漸增大時，需要在客戶端執(zhí)行的 JS 腳本也會越來越多，這也意味著 TTI(可交互時間) 指標(biāo)越來越高:

為了解決這個問題，Islands 架構(gòu)將頁面拆分為各自獨立的組件，包含靜態(tài)組件和可交互組件，如下圖的例子所示：

可以清楚的看到，一個頁面中只有部分的組件交互，那么對于這些可交互的組件，我們可以并行地執(zhí)行 hydration 過程，因為組件之間是互相獨立的。

而對于靜態(tài)組件，即不可交互的組件，我們可以讓其不參與 hydration 過程，直接復(fù)用服務(wù)端下發(fā)的 HTML 內(nèi)容。

可交互的組件就猶如整個頁面中的孤島(Island)，因此這種模式叫做 Islands 架構(gòu)。

相比于傳統(tǒng) SSR 中的全量 hydration，Islands 模式可以實現(xiàn)局部(partial) hydration，從而優(yōu)化 JS 的體積，減少網(wǎng)絡(luò)傳輸?shù)某杀竞?JS 運行時的開銷。

在 Astro 中，默認(rèn)所有的組件都是靜態(tài)組件，比如:

// index.astro
import MyReactComponent from '../components/MyReactComponent.jsx';
---
<MyReactComponent />

值得注意的是，這種寫法不會在瀏覽器添加任何的 JS 代碼。但有時我們需要在組件中綁定一些交互事件，那么這時就需要激活孤島組件了，在 Astro 如何來激活呢？其實很簡單，在使用組件時加上client:load指令即可:

// index.astro
---
import MyReactComponent from '../components/MyReactComponent.jsx';
---
<MyReactComponent client:load />

如此一來，Astro 會給瀏覽器傳輸一部分 JS 代碼供這個組件完成 hydration，以便后續(xù)的交互。

對比 Next.js 和 Remix

讀到這里，你可能會說了，相比于其它的業(yè)界方案，Astro 到底優(yōu)勢在哪里呢？我們不妨來盤點一下。

首先是大名鼎鼎的 Next.js，我們知道 Next.js 是一個非常經(jīng)典的 React SSR 框架，也是使用傳統(tǒng)的 SSR/SSG 技術(shù)，可以適用于幾乎所有的 Web 開發(fā)場景。而 Astro 在其適用的content-focused場景下，性能會明顯高于 Next.js，以下是兩個真實的遷移案例:

可以看到，Astro 相比 Next.js 可以大幅度減少 JS 代碼的體積(90% 以上)，同時頁面的運行時性能也提升了 30% 以上。除此之外，Astro 不僅支持使用 React 框架，而且支持 Vue、Solid 等在內(nèi)的各種前端框架，靈活性更高。

其次是最近比較火的新秀框架 Remix，它基于 react-router 管理組件，通過 loader 和 action 的概念盡可能將邏輯代碼放到服務(wù)端的 bundle，從而減少客戶端 JS 的代碼體積，同樣是崇尚 0 JS 的理念，Remix 卻仍然需要全量 hydration，無法完成 partial hydration。此外，Astro 還有兩大優(yōu)勢:

• 除了 React，也支持其它的眾多前端框架；
• 同時支持 SSR 和 SSG，而 Remix 不支持 SSG。

對比 React 18 的 Selection Hydration 特性

React 18 提供了 renderToPipeableStream API，真正實現(xiàn)了 SSR 場景下的 Selection Hydration，主要有如下的幾個特點:

• 在完整的 HTML 渲染之前就可以進行組件的 hydrate，而不用等待 HTML 的內(nèi)容發(fā)送完畢
• hydration 可中斷。比如頁面中有兩個組件: Sidebar 和 Comment，當(dāng)這個部分的 HTML 發(fā)送至瀏覽器時，React 打算開始對 Sidebar 組件進行 hydrate:

如果用戶在這個過程中點擊了 Comment 組件，那么 React 會中斷當(dāng)前對于 SideBar 組件的 hydrate，從而去執(zhí)行 Comment 組件的 hydrate:

詳情可見 React 18 SSR Architecture: https://github.com/reactwg/react-18/discussions/37

那么 Astro 中的 Islands 架構(gòu)，即 Partial Hydration，和 React 的 Selection Hydration 到底是不是一個東西呢？

答案是否定的。兩者存在著非常大的區(qū)別:

• 從渲染框架上來看，Selection Hydration 依附于具體框架的實現(xiàn)，而Partial Hydration 可以做到框架無關(guān)，即使是 Vue、Solid 的項目也可以做到Partial Hydration。
• 從客戶端執(zhí)行的 JS 總量來看，Partial Hydration 可以做到加載部分組件的 JS 代碼，而Selection Hydration 仍然需要加載和執(zhí)行全量的 JS 代碼。
• 從服務(wù)端和客戶端的交互來看，Selection Hydration 嚴(yán)重依賴于流式(Streaming)渲染，服務(wù)端需要加上transfer-encoding: chunked 的響應(yīng)頭，而Partial Hydration 沒有這個限制。

因此，雖然兩者都是在 Hydration 上做文章，但其實是兩種完全不同的方案，而且 Partial Hydration  更加通用，限制更少，執(zhí)行的 JS 更少。

小結(jié)

以上就是對 Astro 的介紹和分析，后面有機會給大家剖析一下內(nèi)部的源碼實現(xiàn)。文中如有不妥的地方，歡迎大家評論和指正。最后給大家推薦一些 Astro 的學(xué)習(xí)資料，方便大家讀完文章進一步了解:

• Astro 官方文檔: https://astro.build/。
• Astro 實戰(zhàn)系列教程: https://aalam.in/blog/astro-get-up-and-running。

參考資料

[1]Webpack: https://opencollective.com/webpack。

[2]Babel: https://opencollective.com/babel。

[3]Islnads Architecture: https://jasonformat.com/islands-architecture/。