网页形态的发展
在正式开始之前，先介绍一下网页形态发展的历史，方便大家理解。
远古时期：纯静态
发明 HTML 的目的是方便大家看论文文献，所以早期的 HTML 都是静态的，放在服务器上，直接映射本地文件目录结构。
当然那个时候也没多少网页，很多服务并没有网页版本，比如论坛，是以 Telnet 形式提供服务的；文件共享，大多使用 FTP。
古典时期：动态网站
所谓“动态网站”，就是根据用户请求，返回合适的内容。或者换用技术的说法，接受请求之后，从数据库中读取数据，生成页面，返回给用户。其实现在没什么网站不是动态网站了，感觉这是个上个世纪的词，比如去京东上搜“动态网站”，能搜到一大堆书，大多有着深刻的时代印记，比如《ASP+Dreamweaver动态网站开发》，简直辣眼睛。
文艺复兴：伪静态
相比于纯静态网站而言，动态网站通常需要更长的响应时间，而且 URL 也经常难以阅读。比如：/post.php?id=157，没人知道它是什么意思。这个时期的搜索引擎也比较弱，面对类似的网页，会降低权重。所以网站运营方要想办法改进 SEO，就用服务器 rewrite 的方式，把形似静态页的路径指向动态路径，提升搜索排名。
伪静态常常和真静态共同工作，这个阶段 CDN 还不够普及，所以生成静态页面并部署到终端服务器的操作也很常见。
近代：SPA
随着各项技术的发展，浏览器在整个互联网产品中的地位越来越重要，承担的职责也越来越多，最终单页应用（Single Page Application，简称 SPA）脱颖而出，成为最流行的产品形态。关于它的好处我就不一一叙说了，相信大家都了解。
而接下来，MVVM 框架横空出世，一统江湖，更是大大提升了 SPA 的开发体验，同时大大降低了入门门槛。然后，类似的产品如雨后春笋搬涌现。
现代：SPA + SSR
SEO 的问题在 SPA 这里更明显：对于一些不思进取的搜索引擎爬虫来说，SPA 应用里什么内容都没有。而不思进取，是很多统治级公司、统治级产品的常态。所以没办法，它们不适配我们，我们就得去适配它们。然后，服务器端渲染（Server-Side Rendering，简称 SSR）就显得非常必要。
SPA 的 SSR 和以前的伪静态不同。伪静态时期，业务逻辑都是通过后端完成的，前端主要用来收集数据；SPA 时期，大部分业务逻辑已经移到前端，后端只负责数据校验和必要的存储。此时 SSR 的目的是让用户尽快看到第一波需要的数据，接下来的操作仍然由 SPA 负责。所以我们就面临两种选择：
- 前后端共用一套模板，渲染后的页面拥有全部功能，可以继续与用户交互
- 部分页面生成纯静态内容，可以部署在服务器上；其它重交互的部分保持 SPA，独立工作
现代分支：在本地写作的纯静态网站
随着云服务发展，现在很多网站都提供基础的静态网站托管服务，比如 GitHub Pages，我们可以使用一些工具在本地完成静态页面的批量创建工作，然后上传到服务器，拥有自己的网站。
本文的工作实际应该算到这个分支。