Jamstack CMS終於長大了！

本文總結了Brian's Connect.Tech 2019演示文稿（可下載幻燈片）。它探討了Jamstack CMS的演變，重點是從以開發人員為中心的工具到適合非技術內容創建者的解決方案的轉變。

開發人員很容易掌握jamstack的優勢：速度（從CDN提供的靜態資源），安全性（無需妥協的服務器端組件）和簡化的開發/部署。但是，內容創建工作流提出了初始挑戰。儘管傳統的CMS面臨開發人員的批評，但早期的Jamstack解決方案經常負擔非技術用戶的負擔。

最初：以開發人員為中心的生態系統

由於開發人員的採用，靜態現場生成器（Jekyll，Hugo，Gatsby）獲得了知名度。這些通常是開發者建造，維護和內容填充的項目。如2015年O'Reilly報告中所述：

靜態站點生成器是為開發人員構建的。非發展者不太可能對Markdown，Yaml或JSON感到滿意，該格式用於內容和元數據。

即使到2017年（O'Reilly Book與Raymond Camden合著），與WordPress等平台中的Wysiwyg編輯相比，Jekyll Admin和NetLify CMS等早期工具不成熟。編輯經驗要求Markdown和其他標記語言水平。這種有限的主流採用。

成熟階段：基於GIT和API優先CMSS

在接下來的幾年中，兩種趨勢改變了Jamstack景觀：基於GIT的CMS和API-First無頭CMS的興起。

Netlify CMS（開源）例證了一種基於GIT的方法。它提供了用於編輯Markdown，YAML和JSON的工具，而是直接對存儲庫進行更改，從而觸發站點重建。還有其他基於Web的選項，例如林業。

API-First CMSS（內容，DatoCMS，Sanity）提供了更傳統的編輯體驗，存儲內容並通過API提供任何前端。這種去耦與Jamstack非常有效，將內容管理與Frontend Display分開。許多人與流行的靜態站點生成器集成。 Headlesscms.org提供了可用工具的全面列表。 Bejamas的帖子提供了基於GIT和API優先CMS的詳細比較。

儘管這些改進的內容創建，但後端編輯和前端顯示之間的斷開連接仍然存在。缺乏立即的視覺反饋，再加上重建時間，創造了不完美的工作流程。

未來：前端編輯和預覽

jamstack_conf_sf展示的工具架起了此差距。 Forestry的Tinacms（開源）使用基於GIT的CMS為Gatsby和Next.js站點提供了Wysiwyg前端編輯體驗。 Stackbit Live（Stackbit，我是開發人員倡導者）提供CMS和靜態站點生成器 - 敏捷的解決方案，用於註冊編輯和預覽。

這些進步證明了“ jamstack無頭”作為傳統CMS的真正替代方案的生存能力。開發人員經驗和內容編輯可用性之間的權衡正在減少。到2020年，Jamstack CMS已大量成熟。 ??‍？

以上是Jamstack CMS終於長大了！的詳細內容。更多資訊請關注PHP中文網其他相關文章！