Skip to content

与next.js实现方案的对比

LeonCheung edited this page Jun 7, 2019 · 2 revisions

前言

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,将egg router与react-router的配置合并为一个字段进行维护

ssr/csr

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

热替换

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

生产环境部署

  • next.js使用Node原生的http模块来实现Node Server,且绑定的很紧,很难替换为其他框架,且构建生成的服务端和客户端bundle都较大
  • 本应用使用egg作为Node框架,生产环境可以利用cluster充分发挥多核cpu的优势,很容易替换为其他框架作为Node Server。且生成的bundle较小。

总结

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

You can’t perform that action at this time.