Vue CMS 的产品形态
回顾完历史，我们来看看业务需求。
看过我上一次 Chat 《升级工具链吧！使用 Webpack 开发企业官网》的同学应该知道，一切都源自我厂的官网要改版。
我厂官网 v1.0 采用的是前文中“远古时期”的模式，由设计师设计、制作完网页之后，直接把纯静态资源上传到服务器，然后提供服务。这样的好处是：
- 简单好操作，对人员要求低
- 访问速度快，对机器配置要求低
- 对搜索引擎友好
但是也有很多不足：
- 纯静态，不利于调整内容
- 不利于 i18n，没有多语言版
这些问题，我在 v2.0 时进行了修正。首先，我引入 Gulp 做批处理，增加了“发布”环节，虽然最终还是部署纯静态内容，但是内容可以简单调整，也通过 DOM 查找，实现了 i18n，同步提供中英两个语言。
新版本上线一年半，效果不错，但也有很多不足：
- 需要开发者手动管理所有资源，很累
- 发布脚本很多很复杂，不便于理解；Gulp 采用 stream 模式，没搞过的新人很难接手
- 没有好的开发环境
于是，当整个页面内容都要更新时，我决定升级到 v3.0。这次使用 Webpack 工具链，采用多页面模式，配合 Pug 的可编程特性，更好的实现了最终效果，还可以配合 webpack-dev-server 方便的在本地开发。新版本大大改善了开发效率。新同事打开项目看了看 Webpack 的配置文件，很快就搞明白它是怎么工作的，如果要做工作，应该从哪里入手。
不过正如《矛盾论》所说，当主要矛盾被解决，次要矛盾就会变成新的主要矛盾。此刻，新的问题出现：专业的前端开发能很快摸清项目结构，但对于后端同事来说，未知的新概念还是很多。教会他们理解所有框架、类库、工具没什么意义，如果能够给他们一个简单可操作的 UI，那才能真正提高效率。比如 npm run edit，然后浏览器就打开一个页面。他们按需编辑后，保存，提交仓库，发布。这样的流程才是真正要追求的流程。
所以，最合适的做法就是用 Vue 实现一些编辑器组件，它们有两种形态：编辑，静态。编辑态就不用解释了；我们只要把静态的 HTML 保存下来，生成静态页，即可。
好的，现在需求已经出来了：
- 已有一个 Vue 项目
- 这个项目大部分功能由 SPA 提供，不需要静态化，不需要预渲染
- 这个项目部分路由需要生成静态页
- 部署的时候，只需要部署静态页和其引用的资源
看到这个需求，我想大多数关注前端的同学可能跟我一样，第一反应就是：应该找一个 SSR 框架，添加到现有项目中。那么，就选最出名的 Nuxt.js 吧，这个框架的作者还跟 Vue 的作者一起看 NBA 呢。