jamstack？更像Shamstack。

我是Jamstack的忠實粉絲。對於網絡來說，這感覺就像是一個真正積極的發展。我熱切期待即將舉行的會議。

在任何網絡趨勢中，#jamstack似乎最令人遺憾。

- 克里斯·科伊爾（Chris Coyier）（@chriscoyier）2019年5月22日

但是，我想知道首字母縮寫是否完全捕捉了它的本質。雖然我不建議更改它 - 已建立的名稱具有動力，但核心強度在於靜態文件託管。這形成了其力量的基岩，解鎖了幾個關鍵優勢：

• CDN託管所有內容：即使是HTML（Jamstack中的“ M”）受益於CDN託管，這是傳統方法無法獲得的顯著速度提升。這種固有的速度鼓勵在整個開發中保持最佳性能。
• 簡化的工作流程：開發過程是簡化的： git clone ， npm install ， build和通過dist文件夾推送。諸如Netlify之類的平台為每個構建，即使在分支機構上都提供URL，突出了部署的不變性 - 在特定時間點上的文件快照。
• 功能強大的雲功能：缺乏傳統的服務器端語言鼓勵使用雲功能作為服務器端邏輯。這種建築方法與jamstack哲學完全吻合。

至關重要的是，避免將Jamstack限制在Jekyll博客上。儘管靜態站點發電機高度兼容，並且預構建的標記對速度和SEO有益，但這不是強制性的。

客戶端的JavaScript應用程序部署<div>與API相互作用以構建該網站的JavaScript捆綁包仍然有資格為Jamstack。它是靜態託管的（可能），並具有提供數據的雲功能。<blockquote> <p>我會說“是”。也許更多的SSR可能會出於所有原因，但是Meh，而不是jamstack值得徽章所必需的。</p> <p> - 克里斯·科伊爾（Chris Coyier）（@chriscoyier）2019年5月22日</p> </blockquote> <p>jamstack方法鼓勵最大化靜態文件，每當可行時促進靜態內容。雖然通常稱為“服務器端渲染”（SSR），但在部署之前將其描述為在<em>構建步驟</em>中生成的標記更為準確。同樣，不是必需的，而是一個強有力的建議。</p> <p>我們已經靜態託管了HTML和其他資產（CSS，圖像）。然後：</p> <ul> <li> <strong>J</strong> avascript</li> <li> <strong>pis</strong> </li> </ul> <p>這些密切相關。 JavaScript文件可根據需要靜態託管，執行和與API（例如GraphQl端點）進行通信。</p> <p>還可以一種混合方法 - 在依靠JavaScript和API呼籲動態內容的同時預先構建一些標記。考慮一個具有預先構建的主頁和產品頁面的電子商務網站，但是通過API呼叫獲取了動態生成的產品目錄。</p> <p>如果需要新的首字母縮寫詞，將靜態託管並將JavaScript和API組合到“ API”中可能會產生：</p> <p> <strong>tatic</strong> <strong>h</strong> Osting， <strong>pis</strong>和<strong>m</strong> arkup或<strong>shamstack</strong> 。也許不是最好的選擇！</p> </div>

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