我最近開始使用 Astro 來重建最初使用 WordPress、Go、Rails 和 Hugo 建造的副專案。我選擇 Astro 是因為它具有類似 React 的 DX 和良好的語言伺服器支持，並且它與具有慷慨免費套餐的無伺服器託管平台（Cloudflare、AWS Lambda 等）兼容。
當我開始使用 Astro 時，我對它了解不多。現在我已經遷移了多個站點，我想與其他考慮使用該框架的人分享我喜歡和不喜歡該框架的地方。
Astro 的核心是一個靜態網站產生器，能夠在需要時產生動態伺服器渲染頁面。 Astro 非常適合互動性有限的部落格或小型行銷網站。該框架提供了 Next.js 的大部分 DX，而沒有 React.js 開銷。
說實話：傳統的伺服器渲染範本語言嚴重缺乏良好的語言伺服器支援和程式碼格式。與 React/Vue/Svelte 同業相比，Go 模板、Jinja、ERB 和 EJS 在工具方面遠遠落後。大多數伺服器渲染的模板語言無法知道哪些變數在範圍內或它們的類型是什麼。
使用 Astro，所有這些功能都只需一個 VS Code 擴充功能即可實現。
在 Astro 模板內，您可以在模板頂部的「程式碼圍欄」內設定數據，該程式碼圍欄在建置時或回應伺服器上的請求時運行。實際情況如下：
由於模板的所有資料都載入到模板上方的「程式碼圍欄」中，因此語言伺服器可以為範圍內定義的任何物件的屬性提供自動完成功能。它還會指示您何時嘗試使用不存在的變數。
我對 Go 模板、Jinja 和 EJS 等傳統模板語言最大的抱怨之一是它們沒有可以接受子元素的「元件」。我的大多數網站都有某種寬度受限的「容器」UI 元素，這可確保內容不會飛到超寬顯示器上的螢幕末端。如果您有一個手動添加到
的 .container 類，元素，那麼這通常可以正常工作。但是，如果您使用的是像 Tailwind 這樣的實用 CSS 框架，那麼您可能會發現自己將以下程式碼新增至每個頁面範本：Astro 檔案不限於單一插槽：它們可以有多個。
我最喜歡的 Astro 元件功能是它們可以接受程式碼圍欄內的 props。這是一個例子：
該元件可以在另一個文件中使用時接受道具。
我之前已經用 Vite 建立了自己的伺服器端整合。如果您想快速在線獲取某些東西，那麼您希望避免自己建立這種商品功能。 Astro 是內建的。
如果您想在 Astro 頁面或元件中新增自訂腳本，您只需在頁面上放置腳本標籤即可。
Astro 將自動編譯 TS 和 JS 檔案作為網站建置流程的一部分。您也可以編寫使用 Astro 元件內腳本標記內的 node_modules 匯入的腳本，Astro 將在建置時對其進行編譯並將其提取到自己的檔案中。
您可以透過在程式碼圍欄中匯入 CSS 或 Scss 樣式來將 CSS 或 Scss 樣式包含在 Astro 檔案中。
Astro 還提供了透過在 Astro 檔案中使用樣式標籤來執行 範圍樣式 的功能。這個功能對於 Vue 使用者來說可能很熟悉。
給定以下 Astro 檔案：
簡單吧？
操作提供了一種類型安全的方式來運行後端函數。它們提供驗證並可以處理 JSON 和表單資料。它們無疑是 Astro 的殺手級功能之一：所有這些都需要以自訂方式在 Next.js 應用程式中手動連接。它們需要的程式碼比範例多一些，但使用起來非常優雅。我建議閱讀操作文檔頁面。
有無數的 Twitter 開發者說 React 「夠快」。對於很多事情來說並非如此。
我在小專案使用 Rasbperry Pi 4，你可以感受 React 的運行時成本。我確信對於便宜的 Android 手機來說也是一樣的，只不過在這種情況下 JS 開銷也會耗盡電池。
如果我的網站需要的唯一互動性是切換導航選單，我寧願自己連接它。當我需要時，我會很樂意使用 React，但對於許多專案來說，我實際上並不需要它。
我不喜歡 Astro 的地方並不是該框架獨有的：它們是從 JavaScript 生態系統中其他工具借用的想法。
由於 Astro 採用基於檔案的路由，Astro 專案中的一半檔案最終命名為 index.(astro|js|ts) 或 [id].(astro|js|ts)。基於檔案的路由是一種令人討厭的模式，在 Next.js 實現它之後，它席捲了前端世界，並且它有很多缺點：
我承認：當您創建一個頁面少於 10 個的網站時，基於文件的路由感覺很棒。但隨著網站的發展，它會增加摩擦，你與該功能的對抗多於從中受益。
在 JavaScript 生態系統中，Remix 透過提供基於檔案的路由版本而脫穎而出，該版本將所有路由扁平化到單一目錄中，並允許使用者透過手動路由配置完全選擇退出基於檔案的路由。
基於檔案的路由是我對 Astro 最大的抱怨，但這是一個很難逃避的功能。它在 Next.js、Nuxt.js、SvelteKit 等中實作。更奇怪的是，這些框架對於應用程式其他部分的檔案名稱基本上沒有意見。與 Ruby on Rails 相比，大多數 JavaScript 框架在檔案名稱和專案結構方面都為您提供了很大的自由度——除了用於路由。這是一種特殊情況，特殊情況會增加軟體的複雜性。
我真正喜歡的 JavaScript 語言功能是能夠在單一檔案中定義多個變數、函數和類別。這使得可以輕鬆地共置相關功能，而不必因為語言層級的限製而提前將其提取到其他文件。
與 Vue 的單一檔案元件非常相似，Astro 檔案允許為每個檔案定義一個元件。這對我來說很乏味，但 Astro 提供了一種解決方法。
Astro 可以將預先渲染的 React、Vue、Svelte、Solid 和 Preact 元件直接嵌入到其模板中，而無需載入任何客戶端 JavaScript。 Preact 元件與 Astro 合理地配對得很好，因為 Preact JSX 比 React JSX 更接近 HTML。不過，在同一個專案中管理 Astro 和 Preact 元件確實變得很尷尬，一旦我開始使用 Preact 元件，我發現自己將大部分 UI 從 Astro 檔案移到了 Preact 中。
如果您是 Next.js、Nuxt 或 SvelteKit 的狂熱用戶，並且對您的框架感到滿意，那麼您可能不會從 Astro 中得到太多好處。然而，如果您想向使用者減少 JavaScript 的臃腫，同時保留 Next.js 之類的 DX，那麼 Astro 可能適合您。
Astro 面向內容驅動的網站，並提供開箱即用的 Markdown 支援。由於其對內容的關注，它是替代 WordPress 或 Hugo 網站的理想開發者部落格平台。然而，它的功能遠不止於透過操作等功能來實現內容網站。
儘管我非常厭惡基於文件的路由，但我對採用 Astro 最大的擔憂是可能會發生重大變化，迫使我重建網站。 JavaScript 工具比其他語言生態系統中的工具更積極地進行重大變更。因為我對 Astro 還很陌生，所以我不知道從一個主要版本到下一個版本有多少變化。即使有這樣的擔憂，我還是計劃將 5 到 6 個網站從其他平台遷移到 Astro，這樣我就可以利用其一流的 DX 並以低廉的價格託管這些網站。
以上是對 Astro 的第一印象：我喜歡什麼、不喜歡什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
