从上图不难看出，LAMP Stack在操作系统、数据库等方面都有一定约束。到了MEAN Stack阶段，关系型数据库换成了NoSQL，更快更灵活，并且不再依赖单一操作系统。也有团队采用SPA+Node中间层+Go/Python Web Server的模式，前后端团队技术栈分离。如今演进到JAM Stack，架构更加灵活，数据与代码逻辑解耦，站点渲染可以不依赖Javascript，为开发者提供了更大的系统设计与优化空间。
| LAMP（2000年） | MEA(R/V)N（2013年） | JAM（2020年） |
|
|---|---|---|---|
| 优势 |
|
|
|
| 劣势 |
|
|
|
##JAM Stack渲染方案 最近折腾Gatsby博客升级到了v4，瞅瞅初次提交的git代码，已经过去四年了。随着社区日益繁荣、插件体系不断完善，Gatsby也开始卷入云上战场，一图与Vercel、Netlify、Cloudflare、Shopify一绝高下。
在Gatsby 4的feature update中，提到了叫DSG的渲染方法。仔细翻了翻文档，才明白这是提升SSG海量内容构建速度的一种优化。为了减少预构建Markup文档的时间，采纳了按需build的思路。长尾内容请求未命中CDN缓存时，利用边缘Worker的计算能力返回动态结果，并写入CDN Cache。
从上面的请求过程来看，似乎跟Nextjs的ISR增量构建差不多。不过这两种方案还是有一定差异，DSG更像是Gatsby对DPR的实现方式。在ISR方案中，请求未命中缓存时，会回源重新注水，产生一次服务端API调用。而DSG会在每次版本构建时生成一份分离的数据缓存快照。在Cache Miss时，Cloud Worker会用实时的业务代码拉取上个版本的缓存，生成对应的Markup。
Remix最近也有提到自身对渲染的理解，它将页面归类为静态、中间态、动态，可在运行时基于数据、用户、A/B测试等细粒度进行缓存控制。最终的理想将会是，结合边缘计算与CDN，使回源逻辑发生在边缘节点上。
React元框架对比
Nextjs诞生于2016年，基于Node API，与React生态强关联，支持RSC及HTML流渲染；Gatsby在2017年发布1.0版本，初衷是用SSG实现CMS站点建设；Remix于2020年问世，其哲学体现在四个方面，源码内容分离、拥抱网络基础（浏览器、HTTP、HTML）、JS实现渐进增强、不崇尚过度抽象底层技术。
Nextjs |
Remix | Gatsby | |
|---|---|---|---|
| 特性 |
|
|
对比Wordpress等传统CMS来说，Gatsby在开发体验和性能优化方面更有优势，社区的插件丰富度也与Nextjs旗鼓相当 |
| 数据获取与静态化 |
|
|
|
| 部署 | Vercel是nextjs官方部署平台，默认继承了性能优化最佳实践 | Remix由于不依赖Node，可做云函数、容器化、虚拟机部署，Architect、Cloudflare Workers、Netlify、Vercel都支持 | Gatsby Cloud是Gatsby官方部署平台，集成了增量构建、实时预览、边缘计算等能力 |
| 路由 |
|
|
|
| Latest Conf | Nextjs Conf 2021 | Remix Conf 2022 | Gatsby Conf 2022 |
尾声
Nextjs和Gatsby对SSR、SSG的支持是类似的，差异在一些细节的地方，比如nextjs的增量静态生成与Gatsby的增量构建。当然，Gatsby的SSR的能力相对较新，不如Nextjs成熟。
Remix是新生物，只支持SSR。不过，通过适当的缓存头配置，可以达到接近SSG的性能。
当下Web技术日新月异，博客、电商、大数据应用百花齐放。对于框架的选择，很大程度取决于你的应用特性、开发偏好、运维成本、新技术栈包容度等等。