Jamstack 指的是一套用於建構現代網站的技術棧，可能過去的一些文章通常會把它們理解為 JavaScript、APIs、Markup，但其實現在這個概念已經被擴大了，Jamstack 的官網上將它的核心概念歸納為 Pre-rendering、Enhancing with JavaScript、Supercharging with services。
當然掉書袋沒什麼意思，用人話來解釋的話，當下絕大多數 Jamstack 網站，都是這樣的技術棧：
1. 使用網站生成器預渲染整個網站
整個網站在部署前，會被網站生成器（SSG, Static Site Generators）建構和優化為一系列的靜態頁面和靜態資源，這樣整個網站可以被托管在 CDN 上，載入速度得到最大程度地優化，安全性也得到保障。
這裡的網站生成器包括但不限於：Gatsby、Hugo、Jekyll、Eleventy、NextJS……
2. 使用 Headless CMS（無頭 CMS）管理動態內容
如果想要網站承載動態內容，那麼可以接入各種 Headless CMS（無頭 CMS），這些 CMS 系統會對外提供 API，網站生成器可以調用這些 API 拉取數據，將動態數據渲染成為靜態頁面。
這裡的無頭 CMS 包括但不限於：Ghost、Strapi、Netlify-CMS、TinaCMS……
3. 使用 HTTP API 增強網站的功能
在登錄註冊、評論框等需要後端支持的能力上，Jamstack 網站通常會使用微服務提供的 HTTP API，或者一些第三方的 BaaS（後端即服務）能力。
除了以上三個主要特點以外，Jamstack 的網站通常還會有下面的特性：
- 全站托管于 CDN 上
- 原子化發布（每次發布都是一次全量、原子性的發布）
- 靈活的文件緩存策略
- 基於 Git 的全自動建構、部署流程
Jamstack有什麼優勢？
1. 相比于純靜態網站
純靜態的網站很難承載動態的內容，內容改動通常都是要直接修改頁面的程式碼，這對於內容管理人員（很可能是非技術人員）來說非常不友好。
而 Jamstack 的網站，通常會使用無頭 CMS 來將內容管理抽離出去，內容管理人員可以直接在這些 CMS 系統的 UI 介面上進行內容修改，然後觸發整個網站的重新預渲染，以及部署。
2. 相比于傳統動態網站
這裡的「傳統動態網站」指的是用 PHP、Ruby On Rails、JSP 甚至更古老的 CGI 建構的網站，以及基於這些技術產生的建站工具比如 WordPress、Drupal 等等。
這些傳統網站的劣勢在於，它們在運行時都需要一個即時在線的服務端，這些服務端負責處理請求、渲染頁面，這就很大程度上降低了服務的可伸縮性和穩定性（想象一下，你遷移擴容一個在線的 WordPress 網站有多麼麻煩）。
Jamstack 由於是直接使用 CDN 分發靜態的頁面，完全不需要渲染頁面的服務，網站的伸縮性、穩定性可以得到最大的保障。
3. 相比于單頁應用（SPA）
大概五年前，隨著各種前端框架的成熟，越來越多的業務邏輯遷移到了前端處理，這也就誕生了 SPA 的概念，也就是整個網站的 UI 層，由瀏覽器端來完全接管。得益於 HTML5 和現代瀏覽器的一系列特性，這樣的做法可以保證最好的用戶體驗。
但是 SPA 最大的問題在於它對 SEO 不友好，因為 SPA 的頁面內容都是靠瀏覽器非同步獲取、渲染的，雖然 Google 為首的大多數搜索引擎漸漸地支持爬取 SPA 的內容，但是這依然是一個隱患。另外，由於 SPA 需要非同步載入數據，首屏內容需要在在載入、運行 JS 之後才能看到，也給用戶打開網站的體驗帶來影響。
而 Jamstack 的頁面本質上都是托管在 CDN 上的靜態頁面，搜索引擎可以直接爬取這些靜態內容，首屏與靜態網站一樣，可以直接展示內容，而不需要等到載入運行 JS 之後。
4. 相比于 SSR 應用
目前市面上的幾大前端框架都支持了 伺服器端渲染，也就是 SSR 的概念，這些 SSR 技術也成為了 Jamstack 的基礎之一。但是典型的 SSR 應用和傳統動態網站一樣，都是需要一個在線的服務來渲染頁面，同樣會有運維和安全性上的風險。
Jamstack 從技術角度上講，可以認為是 SSR 技術的進階，也就是提前用 SSR 預渲染大部分頁面，然後將這些頁面部署在 CDN 上，隨後根據網站的數據變化，重複預渲染、部署即可。
當然，Jamstack 也不是萬金油，不可能完美適應所有場景，Jamstack 最適合一些內容更新不太頻繁的網站（比如新聞、電商、文檔）。它不適合 Feeds 流、聊天室、論壇、個性化推薦這樣高度動態化的網站，以及郵箱、編輯器這樣偏重型的 Web 應用。
Jamstack的商業價值
在國外的電商行業，Headless Commerce（無頭電商）是一個非常火的概念。
所謂的無頭電商，就是把用戶端的 UI 展現和整個電商後台服務進行解耦，去除掉了 UI 層，也就是「頭」，畢竟每個公司都不想自己的網站、購買體驗和別人一樣。
無頭電商只對外暴露一系列的 API，讓客戶公司可以使用這些 API 建構自己的電商網站。舉一些具體的例子，比如 Salesforce 正在推行的 Open Commerce API，逐漸成為現在電商開放 API 的標準。換句話說，這個做法很類似現在國內很多公司在推行的「中台化」、「大中台小前台」的概念。
所以這和 Jamstack 有什麼關係呢？
你會發現，Jamstack 推行的這一套技術棧，包括預渲染動態數據的靜態頁面、無頭 CMS、微服務 HTTP API，幾乎和無頭電商的理念完全一致，或者說，無頭電商就是 Jamstack 一個最貼切的應用場景。
在前段時間 Vercel 舉辦的 Next.js Conf 上，主要贊助商除了 AWS、Github、Firebase 這樣的雲平台以外，大部分都是適用於 Jamstack 的第三方 API 提供方、或者一些無頭 CMS，這也從側面體現了 Jamstack 目前在國外的生態繁榮。
但是在國內市場上，或許不那麼樂觀：國內 Web 網站本身就處於一個很尷尬的狀態，各大公司的主要業務都是以移動端 App 為主要入口，Web 網站缺少流量來源，或許只有一些特性類型的業務（比如新聞、電商網站）需要 Web 網站；電商市場方面，國內大部分中小型公司都處於嚴重缺乏資訊化的狀態，更多依賴於阿里、京東這樣的大平台方提供的基礎系統，還遠遠沒有自建整套流程的需求，無頭電商也就無從談起。
尾聲
從技術角度上講，Jamstack 本質是一種增強的靜態網站，它的出現很大程度上得益於各大雲廠商提供的雲上能力，包括更容易管控的 CDN/DNS、Serverless Function、DevOps 工具等等。
隨著國內相關雲計算基礎設施的成熟，Jamstack 在國內幾家雲平台的支持程度也會慢慢提高，我們完全可以期待未來 Jamstack 部分替代傳統的 WordPress 等建站工具，變成新一代的建站技術棧。
