渲染的那些事(服务端、spa、预渲染、多页)
由于电商平台的特殊性，即要有实时渲染出来的商品页面、又要有活动页、广告页这种静态页面，再加上多语言国际化支持，所以对于哪一种渲染必须针对特定场景。
1、服务端渲染（ssr）
对于动态页面，以前针对不同的服务端语言使用asp、jsp、php、ejs、jade等等方式，这些模版引擎对后端耦合性比较高，对前端开发很不友好，这也是前后分离重要原因之一，前后分离后，后端只提供API等服务，优点是分工明确、维护大大降低、也利于代码迁移。
那么前后分离后为何需要ssr呢，首先说说spa的问题，首先不利于SEO，因为搜索引擎不会执行js代码，做不到不同页面的head的meta中包含利于SEO的信息；其次加载渲染问题，只有加载js执行后才能请求必要的api接口等，导致渲染延迟。如果网站需要考虑这两种问题的一种，ssr是不错的选择。ssr简单来说就是可以在服务端把必要的请求等操作完成，再把web页面传输给客户端浏览器，这样就能做到不同的head以及首屏的渲染速度了。前后开发代码基本可以复用。
当然还有一些要注意的，服务端运行组件是不可能拿到window等浏览器数据及浏览器接口的，也不能直接操作 DOM，还有比如vue中的生命周期，其实这也很好理解，在浏览器中渲染相关的处理服务端不可能存在，比如mounted，服务端只有beforeCreate、created钩子，而且在beforeCreate、created写的代码需要注意，比如这两个钩子中有setTimeout，然而服务端并没有beforeDestroy 或 destroyed，会导致无法clearTimeout。
另外如果网站支持多语言，那么ssr仍然是比较好的选择，因为当翻译包非常大时，全量加载已经严重影响加载及渲染时，即使根据语言按需加载特定的语言包仍然很大，怎么办呢。由于我没每次加载的只是特定语言的某个页面，并不需要加载此语言的所有翻译，所以可以根据此页面所用到的翻译code获取这些翻译。
2、单页面应用（SPA）
看字面意思我就知道，前端代码基本在浏览器中了。对于CRM系统，把资源加载到前端后处理第一次请求、渲染慢外，之后的操作很流畅，页面之间传递数据简单，当然我们可以用lazy加载相对减少每次请求。对于复杂的业务系统或者管理系统，spa是很好的选择。前提是对首屏渲染速度要求不高和利于SEO方面不做优化考虑的前提下。开发速度上不必说，纯前端开发。
3、预渲染（prerender）
由于SPA项目影响渲染速度，我们可以把部分页面渲染成静态页面，当然这需要nginx额外配置。如果需要使用spa又想加快某些页面渲染速度，可以使用此方式。如果所有页面都想要预渲染，可以选择多页打包。
预渲染原理是使用puppeteer产生的静态资源。
4、多页应用（multipages）
对于广告页、活动页等来说，针对每个需求开发产生单独的静态页面即可。预渲染的方式仍然需要依赖router功能，但是多页无法页面之间通信，所以CRM系统并不适合用多页，除非需要服务端更多的支持。多页配置起来并不复杂，页面之间更加独立，甚至可以指定build指定的页面。在ssr中我们说到多语言处理，我们还有另外一种选择，根据不同的语言直接产生对应语言的静态文件。
最后
之后附上每一种的例子。就像抛开场景谈框架没有结论一样，抛开应用场景讨论那种架构没有意义，因为不同的场景要用不同的架构，同一个项目中可以分拆不同架构，这样的好处即提高性能、效率也减少依赖，比如核心业务如果用ssr创建一个项目，广告页作为一个项目，对于发布版本更加高效，以为互不影响。