网站的未来： Next.js 与 Remix

横向对比

先上一行对比图：

	Next.js	Remix
SSG 静态站点生成	✅内置	不支持
SSR 服务器端渲染	✅内置	✅通过 loader
API 路由	✅pages/api/ 目录下	Remix 就是路由，你可以更加灵活去进行自定义路由
Forms 表单	非内置	✅ 内置，且功能强大
基于文件系统的路由管理	✅ 页面级	✅ 组件级
会话管理	非内置	✅ 内置 Cookie 、Sessions
禁用 JS	未提供充分支持	✅ 静态页面路由
样式	✅ 提供了全局及组件级样式支持 TailwindCSS 等	非内置
嵌套布局	不支持	✅内置
i18n 国际化	✅内置	非内置
图片优化	✅通过 next/image 组件	✅通过简单转换、备选质量等方式
谷歌 AMP	✅内置	非内置
适配器	Node.js Request 和 Response 接口	Fetch API Request 和 Response 接口
Preload	链接自动	非自动
异常处理	创建 404 ，500 等页面	使用 ErrorBoundary 组件局部抛错
Polyfill	fetch 、Object.assign 和 URL	fetch

适用场景 Next.js

静态网站。这是其最大优势。在使用 TailwindCSS 等，可以更加灵活的制作出样式优美的页面及组件。拥有着较为完善的生态圈。

适合快速上手做项目。

Remix

管理后台，对于数据的加载、嵌套数据或者组件的路由、并发加载优化做得很好，并且异常的处理已经可以精确到局部级别。

或许是下一代的 Web 开发框架，需要折腾。

小结

数据复杂，内容较多（如可视化大屏）：Remix
包含表单和会话的管理系统：Remix
SEO 友好的网站：Next.js
纯静态部署：Next.js
国际化支持：Next.js

2022 年 1 月 19 日补：

首先 Next.js 已经很快了，是 SSG 的快。生成了静态的"页面"，但是“页面”是个很大的东西，所以 Remix 的快，可以理解为组件的快，路由即组件。在经过对比了之后，我自己的站点选择使用 Remix 框架，不仅仅是因为快，而是因为这一套东西更“全栈”。Next.js 里可以在 pages/api 目录下写后端。你说它全栈吧，也说得通，但是很多东西用起来很别扭。

从生态角度出发

如果你想快速上手做项目，现阶段（指 2022 年初） Next.js 生态足够强大，Vercel 团队也新进了很多大牛。你想要的，基本都有一些示例的代码，现成的库或者插件。而且 Next.js 本身就内置了 i18n 路由的支持（这是我最喜欢它的一点）。

举个最简单的例子，我想在我的站点上实现 i18n （国际化翻译），Remix 中可用的选择只有一个，remix-i18next ，还是个半成品。在折腾了一周之后，我放弃了先做国际化的最初规划，改向做 mdx 内容管理。同时还有主题切换，也是半成品，remix-themes 插件只支持深浅主题的切换，所以当我选择用 daisy ui 框架的多主题风格时，虽然需要的代码量不算多，我却得写了那么一段塞进了自己的项目里。

小结：如果你愿意折腾，Remix 。新手友好，Next.js 。

从成本角度

Next.js 可以生成纯静态站点，任何类似于 Github Pages 的地方都可以托管。同时 Vercel 个人版本永久免费，团队需要付费。Vercel 的性能非常不错，而且只用按人头来收费（相较于 Remix 的主力平台 Fly.io 来说成本也不算高）。

Remix 则不行，只能跑在服务器上或者 Serverless 服务上。 Fly.io 是容器化的服务，按量（资源使用量）付费，所以业务越大成本越高。Fly.io 目前的模式和收费我个人很难接受，可能我还在幻想着我自己做好的网站能够在很短时间内有爆发的流量增长吧，而且容器化使用的门槛就抬高了，现在所谓的全栈开发更多还是偏向于前端领域。相信对于不是后端的同学来说，写个页面还要考虑 docker-compose 容器文件优化，资源分配调度什么乱七八糟的运维或者侧重于后端的事情，没什么必要。

Next.js ，虽然生态很完善，但这种框架本身的束缚，出于经验的判断我并不会在团队技术选型中用其参与大型项目。这应该也间接反应出一个事情，企业提供服务都是需要考虑成本和收益的。所以 Remix 是有足够信心去支撑大型引用场景的。

小结：如果你并不是产品化的东西，或者预算方面有约束，Next.js 可以满足你更灵活的需求（静态网站、Serverless 托管、服务器或者容器都很 OK ）。Remix 目前来说，并没有一个很好的托管平台。

从性能角度

其实很有意思的一件事情。我们都特别喜欢看框架的性能，却忽略了真正使性能成指数形下降的，大多数是糟糕透顶的业务代码。

Remix 初始性能更强一些，但 Next.js 性能的优化更容易去做。所以就简单讲讲 Remix 性能优化的一些案例：

这也是目前我自己能想到的笨办法，记录每个关键流程的调用时长。Remix 后端性能优化的话目前从有限的文档中看不到特别好的方案，并且由于案例非常少，也没有最佳实践指南。这一部分的注入，很不优雅，但有效。

也可以衍生到 React 与 Vue 框架的对比。我更喜欢 Vue ，尤其 Vue 3 之后加入了更多新的语法糖如 setup 之类的。React JSX 给我就有种代码跟 HTML 混写在一起的原始感觉。而且从性能来说 Vue 是明显在赶超中，框架的初始性能也会高于 React 。但 Vue 的入门门槛低，生态的质量就很难有保障了。

小结：在你没有能力去改变框架性能的时候，关注框架的性能不如关注你用的库、你写的业务，至少这些你都可以去进一步提升它的性能。等你有能力去改变框架性能的时候，PR 不仅仅会让你赢得更多尊重。

建议：你可以更多考虑这个框架在用起来的舒适性。比如说我真的特别喜欢 Vue ，所以我也特别喜欢 Next.js Vue 的版本—— Nuxt.js 。写起来非常惬意，所以即便是我发现做起优化来挺难的，也会乐在其中。

不可否认 Next.js 在现阶段是既方便又好用的框架。Remix 还像一个襁褓里的婴儿。现在谈论它为时尚早，如果感兴趣，可以学习借鉴一下。这篇 Remix 发布的对比博文，和很多文章一样。王婆卖瓜，自卖自夸，说完全客观谈不上，但数据这一块造假的可能性也不大。

以上，是客观的个人观点。

以下，说说主观的个人观点。

就像我喜欢 Vue ，却在写 React 一样。有很多时候，有些因素会干扰我们的选择，就比如说客户定的 Deadline 。使用 Nuxt.js 产品化的路子，就是败给了时间。如果给我更多的时间，我觉得我用 Nuxt.js 也能折腾出更优雅性能更强的东西出来。以后，我可能会在公司产品项目中去尝试使用一下 Remix ，但目前，我 Next.js 还在深入去探索。

折腾这么一个多月下来，我只能说磕磕绊绊，生态等于没有，文档也不全，还的经常去看源码。在反复推翻重做了十几次之后，我打算重新写的个人网站，现在连个顶部导航菜单都还没有完成。

在没有公司 KPI 指标压力的情况下，在没有人指手画脚告诉你这该怎么做那该怎么最佳实现的情况下，在不用赶时间进度的情况下。你喜欢什么去用什么，不是一件快了的事情吗？所以我选择折腾 Remix ，很大一部分原因是因为想要折腾一下自己喜欢的东西。仅此而已。

我并不想去推给别人 Remix 多好你快来用吧，但它很吸引我。就像小时候在电视里看到的棒棒糖非要买来吃，它究竟好吃不好吃并不重要，就是这种简单单纯的抉择，它会让你快乐。