NextJS ​

Making the Web. Faster.

在聊NextJS技术之前，我们需要先了解为什么要用NextJS，即Web应用开发的7个原则；NextJS解决了哪些问题，即Jamstack

Web应用开发的7个原则 ​

谈到NextJS框架，不得不提到Vercel的CEO，Guillermo Rauch。他在14年的时候写过一篇Web应用开发的七项原则，这篇文章很好的反映了NextJS的设计思路。简要概括如下：

• Server渲染页面仍然是必须的

  服务器端渲染与SEO无关，它主要的考虑是性能：需要考虑的包括不在服务器渲染的话，请求脚本、页面样式、页面资源和API请求造成的额外的开销，以及考虑在HTTP2.0里加入的PUSH of resources。

• 对用户输入立刻响应

  我们可以使用JavaScript来掩盖网络的延迟，把它作为设计原则，就可以在你自己的应用里面去掉绝大多数的spinner或者loading。

• 数据变更时的应对

  当服务器的数据变化时，应该主动让用户知道。这样可以使得用户无需经常进行手动的刷新(F5, Cmd+R….)，也是一种性能上的改进措施。新的挑战是：(重)连接的管理，状态的一致性问题。

• 控制与服务器的数据交互

  如何精细的控制客户端和服务器之间的交互。注意出错处理，自动重试，在后台同步数据并管理好离线的缓存。

• 不要破坏history，增强它

  不使用浏览器来管理URL跳转和history，将带来新的挑战。我们必须保证用户在浏览时，应用的表现符合他的期望。可以自建缓存来提高响应速度。

• 推送代码更新

  数据自动更新但代码的更新不是自动推送的应用是低效的。要避免API出错，增强性能。使用无状态的DOM来避免重画。

• 行为预测

  通过行为预测来进一步减少延迟。

这些原则，是从用户体验的角度出发，去思考现有的技术发展方向。我们可以在使用Next的过程中，看到如何通过技术来达成这些设计原则。

Jamstack ​

NextJS是创建Jamstack站点最流行的一个解决方案

Jamstack是什么 ​

Jamstack 指的是一套用于构建现代网站的技术栈，可能过去的一些文章通常会把它们理解为 JavaScript、APIs、Markup，但其实现在这个概念已经被扩大了。

Jamstack 的官网上是这样说的：

• Jamstack 是一种架构方法，可将 Web 体验层与数据和业务逻辑解耦，从而提高灵活性、可扩展性、性能和可维护性。

• Jamstack 不再需要业务逻辑来决定 Web 体验。

• 它为 Web 提供了一个可组合的架构，其中自定义逻辑和第三方服务通过 API 来使用。

主要构成 ​

作为一个构建应用程序的Web技术栈，Jamstack可以类比LAMP、MEAN。但是显然Jamstack没有明确指定数据库、web服务器这些web应用程序构成要件。这是因为Jamstark的出现，很大程度上得益于各大云厂商提供的云上能力，包括更容易管控的 CDN/DNS、Serverless Function、DevOps 工具等等。绝大多数Jamstack网站，都是这样的技术栈：

• 使用预渲染整个网站

  整个网站在部署前，会被静态网站生成器（SSG, Static Site Generators）构建和优化为一系列的静态页面和静态资源，这样整个网站可以被托管在 CDN 上，加载速度得到最大程度地优化，安全性也得到保障。当然随着预渲染技术的不断升级，服务端渲染（SSR，Server Side Rendering）、渐进式的静态内容生成（ISR，Incremental Static Regeneration）、客户端渲染（CSR、Client Side Rendering）以及这些渲染技术的组合会构成非常灵活的渲染体系。

• 使用 Headless CMS（无头 CMS）管理动态内容

  如果想要网站承载动态内容，那么可以接入各种 Headless CMS（无头 CMS），这些 CMS 系统会对外提供 API，预渲染服务可以调用这些 API 拉取数据，将动态数据渲染成为静态页面。相比传统的CMS，Headless CMS将内容与前端/移动应用程序隔离开来，不需要负责管理页面模板和呈现，只关心内容本身，使开发人员能够独立地构建和维护前端。

• 使用 HTTP API 增强网站的功能

  Jamstack 网站通常会使用微服务提供的 HTTP API，或者 Serverless 来提供服务，例如DaaS或者FaaS。

优势 ​

1. 相比于纯静态网站

   纯静态的网站很难承载动态的内容，内容改动通常都是要直接修改页面的代码，这对于内容管理人员（很可能是非技术人员）来说非常不友好。

   而 Jamstack 的网站，通常会使用无头 CMS 来将内容管理抽离出去，内容管理人员可以直接在这些 CMS 系统的 UI 界面上进行内容修改，然后触发整个网站的重新预渲染，以及部署。

2. 相比于传统动态网站

   这里的“传统动态网站”指的是用 PHP、Ruby On Rails、JSP 甚至更古老的 CGI 构建的网站，以及基于这些技术产生的建站工具比如 WordPress、Drupal 等等。

   这些传统网站的劣势在于，它们在运行时都需要一个实时在线的服务端，这些服务端负责处理请求、渲染页面，这就很大程度上降低了服务的可伸缩性和稳定性（想象一下，你迁移扩容一个在线的 WordPress 网站有多么麻烦）。

   Jamstack 由于是直接使用 CDN 分发静态的页面，完全不需要渲染页面的服务，网站的伸缩性、稳定性可以得到最大的保障。

3. 相比于单页应用（SPA）

   大概五年前，随着各种前端框架的成熟，越来越多的业务逻辑迁移到了前端处理，这也就诞生了 SPA 的概念，也就是整个网站的 UI 层，由浏览器端来完全接管。得益于 HTML5 和现代浏览器的一系列特性，这样的做法可以保证最好的用户体验。

   但是 SPA 最大的问题在于它对 SEO 不友好，因为 SPA 的页面内容都是靠浏览器异步获取、渲染的，虽然 Google 为首的大多数搜索引擎渐渐地支持爬取 SPA 的内容，但是这依然是一个隐患。另外，由于 SPA 需要异步加载数据，首屏内容需要在在加载、运行 JS 之后才能看到，也给用户打开网站的体验带来影响。

   而 Jamstack 的页面本质上都是托管在 CDN 上的静态页面，搜索引擎可以直接爬取这些静态内容，首屏与静态网站一样，可以直接展示内容，而不需要等到加载运行 JS 之后。

4. 相比于 SSR 应用

   目前市面上的几大前端框架都支持了服务器端渲染，也就是 SSR 的概念，这些 SSR 技术也成为了 Jamstack 的基础之一。但是典型的 SSR 应用和传统动态网站一样，都是需要一个在线的服务来渲染页面，同样会有运维和安全性上的风险。

   Jamstack 从技术角度上讲，可以认为是 SSR 技术的进阶，也就是提前用 SSR 预渲染大部分页面，然后将这些页面部署在 CDN 上，随后根据网站的数据变化，重复预渲染、部署即可。