jamstack圓桌會議的隨機筆記

上週末在Web Unleashed舉辦了一場JAMstack圓桌討論會。以下是這次經歷的一些零散筆記。

• 我起初很驚訝，“JAMstack”中的“M”代表“Markup”（HTML中的“M”，有時與HTML互換使用），而不是“Markdown”（編譯成HTML的語言）。這確實引起了不少困惑。答案是：JAMstack不需要Markdown。這種混淆源於Markdown經常與靜態網站生成器一起使用，而靜態網站生成器又與JAMstack密切相關。
• 我第一次意識到，託管在Netlify、GitHub Pages或S3存儲桶（“靜態託管”）上的每一個網站都是JAMstack。確實是SHAMstack！ :)。 JAMstack的靜態託管(SH)部分也許是最重要的方面。
• 一個只有一個index.html文件、<div>和一堆JavaScript的網站，客戶端渲染其餘所有內容，也可以是JAMstack。假設它所需的數據要么內置，要么來自其他服務器上的API（而不是託管該index.html文件的服務器），那麼它就是JAMstack。<li> <em>技術上</em>的JAMstack和<em>精神上</em>的JAMstack之間存在差異。上面提到的可能更偏向技術層面，而精神層面則希望預渲染更多頁面。<ul> <li>預渲染的優點在於：速度快、可以CDN託管、安全且對SEO友好。許多框架將其作為其功能的一部分提供，因此您不妨利用它。預渲染並不意味著靜態，JavaScript仍然可以加載並實現更炫酷的效果。</li> <li>靜態網站生成器和JAMstack是最佳拍檔，這一點毋庸置疑。但JAMstack希望您放眼更廣闊的視野。如果您有50,000個產品頁面，而生成速度過慢或不切實際，該怎麼辦？沒問題，您可以預渲染其他頁面，但只需為產品頁面創建一個框架，然後根據需要通過API獲取產品頁面數據即可。如果某些頁面絕對無法靜態託管，該怎麼辦？沒問題，您可以將可靜態託管的頁面代理到靜態服務器，而無需更改其他頁面。想要全力以赴地進行靜態託管，但需要服務器來實現某些功能？考慮使用無服務器函數，它們可以說是靜態託管的精神伴侶。</li> <li>人們真的想知道<em>為什麼</em>。為什麼要費心去做這些事情？如果您可以用WordPress構建一個滿足您所有需求的網站，為什麼不這樣做呢？我最終從功能的角度為我使用WordPress進行了辯護。如果我有無限的時間和一個全新的起點，即使我仍然使用WordPress作為CMS，我認為我可能會走上一條至少進行一些預渲染的道路，如果不是完全解耦並構建我自己的前端，只是通過API使用數據的話。但也許對<em>為什麼</em>最令人信服的答案歸結於<em>速度</em>、<em>安全</em>和<em>彈性</em>，所有這些都在您使用JAMstack時立即獲得。它提供了一個非常棒的基礎來構建。</li> </ul> </li> </div>

以上是jamstack圓桌會議的隨機筆記的詳細內容。更多資訊請關注PHP中文網其他相關文章！