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