“ jamstack”一詞最近引發了活潑的辯論，因為其定義擴展到涵蓋了較新的應用程序。我上一篇文章“靜態與動態與jamstack：線路在哪裡？”，提出了我對jamstack的看法。這篇文章探討了Jamstack的演變及其對術語含義的影響。
靜態站點創建早於“ jamstack”標籤。早期採用通常涉及在GitHub頁面上託管的簡單博客或開源文檔。儘管一些先驅者解決了較大的商業項目，但這並不是常態。
靜態站點曾經被視為過時 - 90年代的遺物。問題出現了：為什麼現代公司會接受這種看似過時的方法？菲爾·霍克斯沃思（Phil Hawksworth）有見地的IJS談話強調了歧義：“我們是在談論靜態體驗還是靜態建築？”
這種歧義，尤其是對於非發展者而言，這是有問題的。現代靜態站點與他們的90年代同行有很大不同。幾個關鍵的技術進步已經振興了靜態場地的開發：
Jamstack重新定義了靜態網站的感知。馬特·比爾曼（Matt Biilmann）在2016年創造了這個詞，捕獲了現代靜態站點的優勢，而沒有“靜態”的負面含義。卡西迪·威廉姆斯（Cassidy Williams）恰當地總結了詹斯塔克（Jamstack）的本質：“ jamstack構建了諸如移動應用之類的Web應用程序：UI已編譯，並且根據需要獲取數據。”
Jamstack與WordPress開發人員產生了強烈的共鳴，與復雜的主題和插件API相比，提供了令人耳目一新的簡單性和控制性。一個社區圍繞著詹斯塔克（Jamstack）脫鉤的建築。
隨著Jamstack的流行，項目規模和復雜性也會增加。 jamstack原則將網站範圍擴展到Web應用程序，突破了靜態站點可以實現的邊界。平台引入了功能和工作流程，以使用Jamstack原理來適應更大，更複雜的應用程序。
CloudCannon參與這一進化是令人興奮的。我們目睹了Web開發的重大轉變，其中一個蓬勃發展的工俱生態系統賦予了前端開發人員的能力，並實現了基於邊緣的複雜應用程序。
挑戰在於對Jamstack的含義缺乏共識。儘管存在簡潔的定義，但該術語對日益動態行為的應用正在導致社區內部的分裂。這種歧義可能會破壞該術語創建的目的。
jamstack的原始解釋和進化的解釋之間的重疊造成了一個困難的問題。儘管我感謝將jamstack原則應用於更具動態的方法，但簡單地創建諸如“ jamstack”之類的新術語可能會加劇困惑。
馬特·比爾曼（Matt Biilmann）對Netlify的分佈式持續渲染（DPR）的觀察很有見地：“對於任何技術，最困難的部分不是建立簡單性，而是隨著時間的推移而保護它。”
這引起了深刻的共鳴。 jamstack的靈活性至關重要。如果項目增長或需要動態功能，則應存在選項。沒有這些選項，jamstack將降級為小規模應用程序。然而，過度強調動態解決方案有可能失去助長jamstack運動的優雅簡單性。
DPR是一個重大進步，優雅地解決了預建大地點的局限性。對於有100,000頁的網站，預先建造子集和按需建造其他網站是值得的優化。
DPR在Jamstack框架中的位置需要仔細考慮。它的包容或排除具有重要意義。肖恩·戴維斯（Sean Davis）的定義引起了共鳴：“ jamstack是一種用於原子建築和交付預編譯，脫鉤的前端網絡項目的架構。”適應此功能以包括DPR需要修改。但是，官方的jamstack定義可容納DPR。
官方jamstack定義的演變值得注意。 “無服務器”的包含反映了其對前端開發人員的可訪問性的增加，但它可能與預渲染和去耦的核心原則發生衝突。這些核心原則需要更新嗎？
Jamstack的未來提出了幾種可能性：
社區中的各種觀點需要共識和明確的前進道路。否則，可能的3、4和5的混合物可能是可能的。圍繞jamstack的熱情是不可否認的，創新令人興奮。需要的是同意前進的道路。
以上是Jamstack的語義的詳細內容。更多資訊請關注PHP中文網其他相關文章！
