編織的網

Jamstack 的一個有趣的悖論：其概念簡單，卻可能導致複雜性。

核心思想是：將預渲染的靜態文件部署到擅長處理靜態文件的Web 託管服務（CDN）上。就這麼簡單。如果需要更多功能，則使用客戶端JavaScript，通常會與無服務器函數配合使用，因為這是Jamstack 後端的理想搭檔。 Guillermo Rauch 最近在Smashing Conf 上提到，Jamstack 並非嚴格意義上的“技術棧”，因為它對具體實現方式幾乎沒有限制。儘管我喜歡“Jamstack”這個詞，但這說法也有一定道理。

諷刺的是，雖然概念簡單，但這簡單性卻可能導致複雜性。

Netlify 公司是Jamstack 的主要推動者，他們深知這一點。他們知道，如果沒有後端服務器和後端語言，像基本的聯繫表單這樣的功能實現起來會很複雜。我們不得不另尋他法來處理表單，而不是直接使用現成的解決方案。因此，他們為你解決了這個問題（以及其他一些問題，例如身份驗證和無服務器函數）。但是，還有許多其他公司也想成為你係統中的一個齒輪。

這只是潛在復雜性之一。你使用什麼CMS 或其他數據存儲？你的構建過程是什麼樣的？你如何預覽內容更改？你如何進行身份驗證？如果你需要一些花哨的日曆小部件怎麼辦？如果你想賣東西怎麼辦？對於網站可以實現的任何功能，Jamstack 都有解決方案——只是將所有這些解決方案結合起來可能會感覺支離破碎且令人困惑。

Dave 最近嘗試使用Eleventy Tailwind Netlify CMS（這是Jamstack 風格的），他說感覺像是在放牧牛群：

我這個小程序原本只打算使用3 種技術，結果卻讓我接觸到了大約20 種不同的技術，並且讓我在午夜後深入挖掘第n 層依賴項的源代碼。如果有什麼比喻能說明我不喜歡現代Web 開發的方面，那就是這個。你想使用三種工具，但你卻不得不學會使用二十種工具。如果模塊和組件像樂高積木，那麼這就是把整個積木箱都倒在地上，只為了找到你需要的一小塊積木。

“我們編織的錯綜複雜的網絡”，確實如此。

在Richard MacManus 和Matt Mullenweg 之間的談話¹中，Richard 引用了Matt 的話：

“你可以將十幾個服務拼湊在一起，每個服務都有自己的帳戶和賬單，每月花費數百美元，才能獲得與在共享主機上使用WordPress 獲得的類似結果，”他說。 “而且它會更脆弱，因為鏈條的強度取決於最薄弱的環節。你將不同的工具集、登錄、賬單、託管……連接在一起；任何一部分出現故障都可能破壞整個流程。”

如果我正在考慮為某個項目使用Jamstack，而最終總共有十二個服務，我可能會重新考慮，特別是如果我可以使用WordPress 並將其減少到一個服務。 Jamstack 還有許多其他合理的批評，尤其是在其發展早期。例如，“帶有預覽功能的CMS”的故事並不是很好，而這是WordPress 上你甚至不會考慮的功能，因為，顯而易見，它具有該功能。

Jamstack 也確實做了一些我非常看重且領先於其他技術的事情。基於Git 的部署？所有網站都應該具備這個功能。我的拉取請求預覽？太棒了。亞100 毫秒的首個請求？求之不得。不必擺弄緩存？太爽了。趕上吧，其他技術棧。

我的意思是，這裡需要做出“金發姑娘”式的選擇。你可以通過做你可能已經在做的事情來做到這一點：穿上你的成人褲子，考慮你的項目需要什麼，然後選擇最佳方案。

我有一些生產環境的WordPress 網站。就像這個！很棒！

我也有生產環境的Jamstack 網站。就像這個！它不是一個複雜的網絡服務。它是一個靜態網站生成器，內容位於GitHub 倉庫中，並使用Netlify 部署。雖然CSS-Tricks 可以做大約100 件這個網站無法做到的事情，但它也有一些CSS-Tricks 做不到的技巧，例如接受內容的拉取請求。

我覺得在我的所有案例中，我都選擇了相當不錯的方案。

1. 雖然Matt 明顯有動機來捍衛WordPress 的方法，但我感覺這裡的觀點是真誠的；部分原因是Automattic 投資於替代技術棧方法，並且WordPress 和Jamstack 並不相互排斥。我喜歡對此的回應，例如Ohad Eder-Pressman 的公開信，其中也充滿了帶有動機但真誠的想法。

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