慣性

Jeremy 對開發者工具的分類一直讓我印象深刻：

我曾提到過兩種類型的Web 開發工具，但我仍然不太確定該如何稱呼這些類別。內部和外部？面向開發者和麵向用戶？

第一類包括構建工具、版本控制、轉譯器、預處理器和代碼檢查器。這些工具運行在你的機器上——或者服務器上——接收你編寫的代碼，並將其轉換成Web 的原材料：HTML、CSS 和JavaScript。

第二類工具是由Web 的原材料構成的：CSS 框架和JavaScript 庫。

這是一個很好的思考方式，當然也有一些細微之處。 Sass 屬於第一類，因為它不會直接交付給用戶，它只生成交付給用戶的CSS。但它仍然會影響用戶，因為它生成的CSS 大小會根據你的使用方法而有所不同。

Jeremy 將Svelte 稱為一個庫，其目標是在代碼交付給用戶之前盡可能多地進行編譯。仍然會有一些JavaScript 代碼，但它不包含面向開發者的API 的開銷。這裡的細微之處在於Svelte可以以一種完全移除所有JavaScript 代碼的方式使用。例如，SvelteKit 可以完全關閉其水合功能，並對頁面進行預渲染，從而創建一個完全無JavaScript 的網站（或者至少只在你需要時才使用它）。

關於React：

我知道有一些方法可以讓React 的行為更像第一類工具，但這絕對不是默認行為。而默認行為真的非常重要。對於React 而言，默認行為是假設你編寫的全部代碼——以及你用來編寫它的工具——都將發送到最終用戶。

我認為這是合理的，但故事似乎也正在慢慢發生變化。我認為廣泛應用還很遙遠，但服務器組件在這裡值得關注，因為它們來自React 團隊本身，就像SvelteKit 來自Svelte 團隊本身一樣。

關於Astro：

[…] 與Svelte 不同，Astro 允許你使用與現有框架React 相同的語法。因此，如果你已經學習了React——因為你需要學習它才能找到工作——那麼你無需學習新的語法就能使用Astro。

我知道你可能無法一鍵將現有的React 網站轉換為Astro，但至少有一個明確的升級路徑。

這不僅在理論上是正確的，而且在實踐中也是正確的！

我剛剛將我們的小型無服務器微型網站從Gatsby 轉換到了Astro。 Gatsby 基於React，因此所有組件都是作為React 組件構建的。 Pull Request 比較混亂，但它在這裡。我將其中一部分轉換成了.astro 文件，但將許多組件基本保持不變，作為.jsx React 組件。但React不會發送到用戶的網站上。網站上的JavaScript 代碼幾乎完全被刪除了，只保留了一些手寫的原生JavaScript 代碼用於非常簡單的交互。

所以這裡有一些拋硬幣的事情發生。硬幣合併？對我來說，Astro 感覺非常像一個面向開發者的工具。它幫助我。它使用Vite 編譯器，速度非常快，使用起來也很愉快（Astro 肯定還有一些不足之處，因為它還沒有達到1.0 版本，但DX 在很大程度上已經實現了）。它對我的樣式進行作用域限定。它允許我編寫SCSS。它允許我編寫組件（使用許多不同的框架）。但它也幫助了用戶。網站上根本沒有JavaScript 包了。

我想這意味著Astro 沒有改變類別——它是一個面向開發者的工具。它只是碰巧將原本面向用戶的工具（甚至是Svelte）變成了幾乎完全面向開發者的工具。

因為我還有幾個關於Astro 的鏈接一直放在口袋裡，Flavio 有一個很好的入門教程，這裡還有Drew McLellan 和Matthew Phillips 在最近的Smashing Podcast 上討論Astro。

這裡還有Dave 和我討論我最近用Astro 重做的網站：

以上是慣性的詳細內容。更多資訊請關注PHP中文網其他相關文章！