作者 | 繁易
如果你之前從未了解過 Jamstack，我推薦先閱讀文章：Jamstack，下一代Web建站技術棧？（
https://zhuanlan.zhihu.com/p/281085404）。
Jamstack 是什麼？
Jamstack 是一套用于建構現代 Web 站點的技術棧，擁有高性能、安全性、易擴充的特性。
Jamstack 技術棧 & 生态
Jamstack 聚合了現代前端開發所需要的腳手架，架構，工作流等，進而最大化的提高工程師的生産力。
工作流
在這裡，Jamstack 的核心理念是預渲染、使用 JavaScript 實作動态功能、使用 HTTP Api 連接配接第三方服務。
舉個例子
當你要開發一個部落格，在這之前你可能會使用 Wordpress 去搭建你的部落格站點，但與此同時，你也需要負責維護 Wordpress 的服務與資料庫等。
而如果你使用 Jamstack，你可以使用諸如 strapi 的 headless cms 服務(意為隻提供 API 而不提供頁面渲染)，用來存放你的文章資料，你在前端可以使用類似 Next.js 的架構去構造站點，通過請求 headless cms 的 Api 來渲染頁面。
而在釋出時，你将在建構時生成靜态頁面，并釋出至 CDN。因為是靜态頁面，是以性能好，而托管至 CDN 意味着該頁面是隻讀的，安全性高，且 CDN 是全球部署的話，那麼頁面也能實作全球部署，拓展性非常好。
誤區
Jamstack 在國内落地時，總是會有同學認為這是新瓶裝舊酒，或者是前端炒出來的新概念，但實際上忽略了 Jamstack 自身架構的特性與優勢。
Jamstack 是不是新瓶裝舊酒
Q：Jamstack 和之前的手動釋出頁面到 CDN 有什麼差別，是不是新瓶裝舊酒？
A：這裡我可以很明确的給一個答案：不是。
首先在我看來，Jamstack 雖然表現的都是頁面和資源托管至 CDN，是實際上背後的工作流與過往是截然不同的。相較于以往手動開發和釋出的模式，Jamstack 是聚合了現代前端架構、工作流、釋出平台的，這一點非常的重要。
對于工程師而言，效率就是生産力，之前的頁面不一定是基于現代工程的，每次生成靜态頁面也依賴于自己寫的腳本，每次頁面更新還需要手動釋出，效率偏低。而使用 Jamstack，你可以利用你最熟悉的架構，通過架構去批量生成靜态頁面，并且聚合 Git 等服務，實作推送即釋出的全自動工作流。效率會高很多。
舉個相似的例子：使用 React/Vue/Angular 和使用 jQuery 寫頁面，最終都是操作 DOM，是以 React/Vue/Angular 和 jQuery 是一樣的，新瓶裝舊酒？
先進的工具帶來先進的生産力，即使最終的表現是前端頁面和十年前一樣，部署至 CDN。但實際上生産效率與品質還有可生産的頁面已經發生了很大的進步。
不論是什麼前端頁面，能打開的更快終究是更好的，是以如果隻關注到部署的結果，而沒有注意到生産流程與生産效率的變革，便會落入“Jamstack 是新瓶裝舊酒”這個論點的坑中。順帶一提，近幾年的前端工具基本上也是朝着“性能更好”、“更易用”等方向去前進的。
Jamstack 能适應所有的場景
Q：那是不是什麼網站都上 Jamstack 就對了？
A：明确的回複，不對，Jamstack 的優勢非常明顯，是以劣勢也很明顯。
如果隻關注到 Jamstack 的性能優勢，希望将 Jamstack 用于所有場景，其實是不正确的。Jamstack 的站點為了獲得性能、安全、可拓展性的優勢，需要将頁面托管至類似 CDN 的服務中，這個過程中，一個頁面需要經過以下兩步才會真正的釋出到線上。
- 預渲染
- 需要提前渲染出最終的頁面
- 釋出
- 托管服務重新整理緩存後展示新頁面
針對預渲染，由于往往需要在建構時或者運作時實作功能，那麼會存在一定的限制。建構時生成無法實作千人千面，運作時生成則需要考慮生成的數量與成本的考慮。假定将每一條微網誌都生成一個靜态頁面，誠然性能是好了，但所帶來的成本也是不可估量了，且許多微網誌往往通路的人極少，那麼運作時生成的性能可能還不如之前，
在 Jamstack 架構下，CDN 是最常見的托管服務，但 CDN 為了保證性能也存在着緩存的機制，這意味着頁面的實時性無法保障。現有的 Jamstack 架構也會添加定時生成的功能，比如每 10S 就重新整理一個頁面并推送至 CDN，但不論怎麼做，在實時性上還是不如實時服務的。
Jamstack 最适合一些内容更新不太頻繁的網站（比如新聞、電商、文檔）。它不适合 Feeds 流、聊天室、論壇、個性化推薦這樣高度動态化的網站，以及郵箱、編輯器這樣偏重型的 Web 應用。
Jamstack 會是企業級架構的核心特性而非唯一，混合渲染是未來方向
這個觀點是我個人的想法。
在我看來，之是以 Jamstack 在國内難以落地，除去老生常談的工作流、部署平台、底層依賴的限制外，其實還存在着适用範圍單一的問題。
這裡我抛出我的觀點：在國内的市場下，Jamstack 将會成為企業級架構的核心特性，但并非唯一的特性，混合渲染才是未來的方向。
誠然，Jamstack 的優勢非常明顯，用過的同學都說省事都說好，但我在前文也提到了 Jamstack 的劣勢，這決定了在企業内部錯綜複雜的場景中，Jamstack 不是那麼萬能的。
此外，Jamstack 作為一種現代 Web 站點的開發理念，其是易于被架構實作的。這也意味着，在企業級的場景中，往往會是架構去實作 Jamstack 特性，這個過程是新增而不是替換。是以 Jamstack 會是企業級架構的核心特性而非唯一特性。
至于後一句提到的混合渲染，Idea 實際上是源于 Next.js 10。在 Next.js 中，架構配合 Vercel 雲服務平台，實作了純靜态頁面托管、增量生成、服務端渲染等多種渲染政策的聚合。從這個角度來看，Next.js 相較其他的 Jamstack 架構是更有優勢的。
靜态生成
增量生成政策
先進的架構 + 先進的工作流 + 更多渲染場景的适配，我認為這才會是企業級架構進步的方向。
總結
Jamstack 是一套優秀的現代 Web 站點開發技術棧，在現代前端工程的加持下解決了開發效率與性能的難題。但由于其劣勢也非常明顯，是以在企業級架構中，Jamstack 會是一種核心的特性，但不是唯一的特性，企業級是需要支援類似混合渲染的開發模式的。
BTW，本文沒有提及到使用 JavaScript 與連接配接第三方服務這兩個特性，理由是：建構現代站點，完全脫離 JavaScript 不現實，故略過；預渲染頁面時，往往就包含使用第三方服務（當然我覺得這一點的商業價值實際更大），故也略過。
推薦閱讀
Jamstack，下一代Web建站技術棧？
https://jamstack.org/Next.js - Data Fetching