静态页面开发新姿势
到目前为止，前端开发方法有以下几种：
- 传统静态页面：不使用框架，手撸DOM；
- 传统服务端渲染：HTMl作为模板，由服务端渲染完成；
- 单页应用：使用MVVM框架前端渲染；
项目特点
所谓静态页面项目，只项目中大多数为无交互逻辑的展示型页面。如产品介绍，官方网站，内容发布等项目，都属于静态页面项目。
结合业务，静态页面的项目需要满足以下特性
『静态』页面
顾名思义，这类项目绝大多数内容都是静态的，是写死在项目里的。
SEO友好
因为此类项目往往用于宣传，所以一般依赖搜索引擎引流，SEO是必不可少的。
快速打开
此类项目的用户往往没有明确的目标，抱着随便看看的心态。如果网站首屏加载速度较慢，会损失一部分弱网环境的用户。
单页可拆分
此类项目页面不多，但内容很丰富，我们需要将大页面中的解耦元素进行拆分，独立开发， 这样做的好处就不再赘述了。
最佳实践
为了满足上面的特性，我们需要综合考虑不同开发方法的优劣，得出最优解。以下是几种开发方法的对比：
| 方法 | 首屏打开速度 | 体验 | 开发效率 | 可维护性 | SEO | 成本 |
|---|---|---|---|---|---|---|
| 传统静态页面 | 极快 | 差 | 极低 | 极低 | 一般 | 高 |
| 传统服务端渲染 | 快 | 一般 | 低 | 高 | 好 | 极高 |
| 单页应用 | 慢 | 好 | 高 | 极高 | 差 | 低 |
通过对比可以看出：
- 在不考虑开发成本和硬件成本的情况下，比较符合我们预期的是传统服务端渲染；
- 单页应用虽然成本低，效率高但首屏打开速度过慢，SEO几乎不支持，这不符合项目的要求，所以不考虑；
- 针对一些流量较大，逻辑简单，开发时间充裕，不需要长期维护和迭代的项目，传统静态页面比较符合我们的需求。
新想法
我们发现，这几种方法都是优缺点互补的，如果能把这些好的地方集合到一起形成一种新的开发方法，就太好了。
单页应用的预渲染
即编译时将单页应用渲染一次形成多页应用。结合静态页面的「静态」的特点，预渲染的页面首次加载与加载完成几乎没有差别。
单页应用的服务端渲染
即服务端提前将动态加载的数据渲染成为可直接浏览的页面后返回，这可以很好地解决SEO的问题。
结论
- 使用单页应用的
Workflow快速高效开发； - 将纯静态页面预渲染，放在CDN上；
- 使用服务端渲染含有动态数据的页面。
技术栈选择
Next.js (React) 和 Nuxt.js (Vue) 都可以很好的实现需求，但精益求精，还是可以作一些对比出来。
加载速度
Vue 的依赖收集机制在强交互，状态大量改变的场景下表现地很好。但相应的，首次加载或刷新页面时，它需要一些时间来收集依赖。考虑到我们项目各种意义上的「静态」，Next.js胜出。
上手难度
Next.js是从零配置的，需要一些时间来搭建适合业务的项目，Nuxt.js是开箱即用的。作为项目的开发者，Next.js的上手难度要低一些。
开发效率
毫无疑问，Vue的效率要高一些。但此类项目交互逻辑简单，所以开发效率不是我们考虑的重点。
可维护性
JSX 非常适合这种需要频繁拆分组件的场景，而且React对Typescript的支持也更好。
影响力
Next.js坐拥庞大的React社区，由ZEIT开源。有非常多著名的产品站和官网，都是使用Next.js开发。
这里看：https://nextjs.org/showcase
最后选择 Next.js 作为主要技术
工作栈
样式处理
围绕React样式的问题一直以来都是热点。依然是结合业务：我们需要编写很多组件和CSS代码。所以我更偏向于CSS-in-js。这样可以保证这些组件的样式没有命名空间冲突的问题，目录页更好组织。
得益于预渲染的好处，编译时写在Js里的CSS就自动转化为了内联样式，顺手还解决了样式闪烁 (FOUC) 的问题 。
兼容性
使用Typescript与Babel相结合，添加各种腻子保证兼容性。
热重载
Next.js是基于Webpack的
Lint
Eslint配合Prettier，自动修复各种风格差异，保证项目风格一致。
资源文件
- 所有资源文件直接从CDN拉取，防止项目过大，项目文件混乱；
- 图片提前裁剪至合适尺寸上传至CDN。