“ 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中文网其他相关文章！
