与next.js实现方案的对比

前言

next.js是很成熟的搭建React SSR应用的框架。其作者兄弟同样也是Vue SSR应用框架nuxt.js作者。在本项目egg + react + ssr骨架的实现过程中，也有很多思想参考next.js。在此过程中对next.js的源码有了一定的了解。本应用几经改良后，在此处给出本应用与next.js的不同之处。如有差错，欢迎刊误。

方案对比

读取服务端bundle

• next.js本地开发读取服务端bundle采用的方式是将bundle以开发环境的模式构建到本地，在每次源码有变动时在本地生成新的服务端bundle，使用hot-middleware + dev-middleware + fs 实现。
• 本应用是直接采用webpack --watch + inline-sourcemap 的方式将文件写到本地，实现更加简洁。

本地开发生成的bundle大小

• next.js本地开发的时候会生成非常非常多的文件，并且你打开一个非常简单的应用打开要加载将近2.5m的静态资源文件
• 本项目生成的budle大小为同样复杂度next.js项目的0.4倍，且只生成3个文件

路由

• next.js将react-router搬到项目中，且加入了非常多的自定义方法是个黑盒。使用声明式路由无需手动编写路由配置。
• 本应用直接使用react-router,依旧使用传统的spa应用的使用方式手动编写路由规则的方式，更加方便你去控制你的项目结构。并将egg router与react-router的配置合并为一个字段进行维护

ssr/csr

• next.js是一个纯粹为ssr应用服务的框架
• 本应用即支持ssr也支持csr，且支持本地开发与生产环境ssr/csr两种渲染模式无缝切换

热替换

• next.js采用hot-middleware + webpackHotDevClient.js实现
• 本应用直接用社区的热门库webpack-dev-server实现

总结

个人感觉而言，next.js还是属于一个过度封装的框架，其中太多东西是黑盒了并且耦合的很紧密，如果想换一种实现方式都很难。且只支持ssr一种渲染模式。并且next.js考虑的东西太多了，即使是一个非常简单的应用也需要做很多不必要的工作。 本应用经过多次完善，目前的实现方式比next.js轻便很多，且封装程度不高，利于开发者修改配置。同时支持两种渲染模式。