客户端渲染：Next.js 一样可以用啊，加上 use client 指令之后对应的页面就是首次访问是 SSR ，然后用 next/link 的 Link 组件点击或者 useRouter 的 push 也是客户端渲染，路由体验一点也不差啊

缓存数据：这不是后端输出 API 时需要在 header 设置强制缓存和协商缓存的吗？然后 vercel （ next.js 的母公司）本身也有推出 useSWR 啊，stale while revalidate 的理念就是缓存+后台刷新，体验也不差啊

BBF：BBF 为什么要跳过？ Next.js 的 CSR 服务端组件直接就是 BBF ，少了一层单独的 BBF 代码，维护性好了很多

自由度：看你怎么取舍，软件开发没有银弹，我之前也试过不用任何框架，手动用 react-dom/server 处理 SSR ，手动用 import()+React.lazy 做路由分割，手动用 webpack 打包精准控制每个 plugin 和 loader 参数以及公共 vendor 包的分割，然后发现自己花了大量时间处理工具链问题，不如 next.js 官方的默认配置来的好用，甚至性能还有所降低。举个例子，如果用了 css module ，你自己不花一番功夫配置各种 ts 插件，在 VSC 或者 WebStorm 等主流开发工具里面是无法做到 F12 点击 css module 的 className 名称后自动跳转到原始 css 文件对应的 className ，如果你看过 next.js 官方的源码你会发现他做了非常多的类似的优化以及各种方便开发者的组件

目前来看 remix 最大的优势是开发阶段用的是 vite ，hot-reload 速度比 next.js 的打包后提供预览的方式要快很多。我昨天刚好在看 turbopack 的文档，里面有提到 next.js 为什么不用 vite 或者浏览器暴露原生 ESM ，https://turbo.build/pack/docs/why-turbopack

我之前也在 twitter 提到过 remix 和 next.js 的差别 https://x.com/changwei1006/status/1819012445643645186 。怎么选择就看你本人对 Vercel 和 W3C 标准化组织的哪个更有信心和期待。next.js 的理念就是目前前端标准进步速度太慢，这种环境下做一些激进的优化很困难，干脆我自己用 Next.js ，next/image ，next/font ，SWR ，RSC 来解决路由，图片，字体，缓存，交互等方面的性能，而 remix 是尽可能使用前端标准下的各种方案做优化。

目前来看我个人还是觉得 Vercel 的影响力，技术实力和在用户体验方面的推动力要比 W3C 大很多，所以我会选择 next.js ，这也是大部分开发者的观点和选择。