是否靜態？

靜態網站生成器？我為什麼不用？ Kev Quirk 的簡短評論：Kev 使用WordPress：

想在iPad 上寫博客？沒問題。想在手機上寫？也可以。在我不常用機器上寫？只要有瀏覽器，一樣沒問題。

首先，值得一提的是，使用WordPress 並不意味著你不能使用靜態網站生成器。 WordPress 有一個API，這使得在構建過程中調用API 來構建你的網站成為可能。 Gatsby 就是這麼做的，它有一個導出靜態網站的插件，而像Frontity 這樣的項目則模糊了界限。

但我同意Kev 的理由。基於他的所有理由，以及其他無數理由，運行一個WordPress 網站是一個完全可以接受的，而且通常是明智的選擇。我認為這關乎健壯性和功能的完備性。需要電子商務功能？ WordPress 有。需要表單？有很多優秀的插件。需要增強CMS 的功能？你可以控制內容類型及其內容。需要身份驗證？這是核心功能。想要出色的編輯體驗？ Gutenberg 棒極了。

一次又一次，我快速高效地用WordPress 構建我想要的東西，這讓我感覺高效且強大。但我不想特別談論WordPress；這同樣適用於任何“經典”CMS。 Craft CMS 原生就具有GraphQL API。我們剛剛發布了一個關於Drupal Jamstack 網絡研討會的帖子。

在相對較新的靜態網站世界中，一件小事最終可能變成一段漫長的研究和實施過程，感覺就像你是地球上唯一一個這麼做的人。

話雖如此……

我對靜態網站生成器和Jamstack 世界的看法如何？它們很棒。

我認為以這種方式構建網站有很多好處。數據和前端的分離很明智。安全性很高。開發人員體驗也很好，部署預覽和基於Git 的一切都很棒。啟動速度驚人（從CDN 提供HTML 服務是一項壯舉）。

就像經典的服務器端CMS 不會阻止你構建靜態網站一樣，使用靜態網站也不會阻止你做動態的事情——甚至是超級高級的動態事情。 Josh Comeau 有一篇很棒的新文章深入探討了這一點。他構建了一個在瀏覽器中使用React 完成大量工作的漂亮小應用程序，但這並不意味著他仍然不能靜態地提供大部分內容。他稱之為“思維方式的轉變”，指的是你可能認為你需要數據庫調用，但你真的需要嗎？數據庫調用是否已經發生並生成了一個靜態文件？如果沒有，那麼仍然可以靜態生成一部分內容，剩下的部分動態獲取。

我期待著一個世界，在這個世界裡，我們開始真正看到兩全其美。我們盡可能多地靜態生成內容，通過API 獲取我們無法靜態生成的內容，並且在整個過程中不會犧牲最佳工具。

何時選擇靜態網站……

• 如果你可以，你應該考慮一下，因為它的速度和安全性無與倫比。
• 如果你正在處理一個Greenfield 項目。
• 如果你的項目構建自並使用可訪問的API，你可以在構建過程中調用該API，以及在初始HTML 加載後使用它。
• 如果某個靜態網站生成器看起來非常適合你正在做的事情。
• 如果成本分析表明它更便宜。
• 如果某些功能（如構建預覽）對工作流程非常有幫助。

何時選擇服務器端軟件……

• 如果你需要經典CMS（例如WordPress）的功能，並且從那裡轉向靜態的的技術債務太高。
• 如果你已經深入參與了一個服務器端渲染項目（Ruby on Rails、Python 等），並且沒有遇到任何現有問題。
• 如果你團隊在該領域擁有最多的專業知識。
• 如果成本分析表明它更便宜。
• 如果沒有針對你想要構建的內容的好的靜態解決方案（例如論壇軟件）。
• 如果你遇到極端情況，例如數百萬個URL，並且靜態構建時間太長。

選擇靜態網站的錯誤理由……

• 你需要使用服務器。 （為什麼？你仍然可以在構建時或運行時調用服務器上的API。）
• 你需要身份驗證。 （為什麼？Jamstack 可以通過JWT 等完美地實現身份驗證。）
• 你甚至都沒有考慮過Jamstack 方式。

選擇服務器端軟件的錯誤理由……

• 你甚至都沒有考慮過Jamstack 方式。
• 因為你認為使用舒適/現有/經典/成熟/受支持良好的工具會阻止你靜態構建任何內容。
• SEO 之類的問題。 （如果有什麼不同的話，靜態渲染的內容應該表現更好。但是，如果轉向靜態意味著轉向客戶端調用來獲取產品數據等內容，這是可以理解的。）

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