为什么 remix 和 nextjs 使用率差那么多？

客户端渲染：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 ，这也是大部分开发者的观点和选择。

1. nextjs 出来早，star 积累更多，围绕他的三方生态也更多
2. 母公司 vercel 和 react 团队非常亲密，很多员工就是从 react 过去的，会给予很多扶持，比如 react 文档优先推荐，合作开发 RSC, 会给用户一种感觉，那就是 nextjs 就是 react 的 ssr 版本。
3. nextjs 营销预算占比更多
4. 马太效应，强者越强，nextjs 员工更多，开源贡献者更多，像好的文档，演讲，场内场外活动都需要大量资源来支持

不过也有不少人认为从 appdir 开始，next 过于激进了，会给用户更多强迫性，还有魔法代码也更多了，reddit 上已经出现了很多弃坑 next 的声音。

@changwei 这样的页面就是没有 SEO 的，比如你需要 async getPostById(), 页面必须是 RSC ，路由跳转必定会产生一次 _rsc 请求，这个过程页面是会卡顿的（取决于网络情况），当然可以加 Loading 去缓解，但是这无法利用好客户端已经拿到的数据做渲染，无法做到类似 twitter 的跳转体验，timeline 上已经拉到 tweet 数据，点进帖子的时候已经有数据可渲染页面，不卡顿，这时候再请求一次 server api ，刷新 tweet 数据（一般没变化），用户感受不到页面跳动。

clientLoader 的功能 nextjs 是没有的，只要页面需要 seo ，每次跳转都会产生 _rsc 请求。remix 可以做到首次请求页面用 server loader ，之后在客户端用 clientLoader ，这样可以充分利用客户端提前加载的数据，比如电商首页，预先拉 product 信息，点击 /products/123 直接用客户端的数据渲染，再补一次服务端请求，按你说的 nextjs 做法 /products/123 这个页面是 client component ，失去了 SEO 。

@fescover 我说的功能也和 nextjs 的商业模式冲突，vercel 希望每次页面请求都会经过他们的 edge server 渲染处理，但是从用户体验角度，我只想让用户首次访问的时候是 SSR （也方便 SEO ），之后是 CSR ，这会让 vercel 的 server request 大幅下降。nextjs 在 page router 出过一个 API：getInitialProps ，首次在服务端请求，之后在客户端请求，后面弃用了。

框架无差 都比较强，nextjs 依靠 vercel 背景比强大 宣传到位，再加上 react 跟 nextjs 团队的紧密合作 先天 buf 加成

看看 react 这两年的版本 不说全部，感觉最起码 1/3 是为了 nextjs 而做

我觉得你举的 twitter 的例子是正好是 timeline 中的数据可以用来渲染详情的场景，如果详情的数据很大，比如商品只能通过 timeline 中点击某个推携带过去 id ，再通过 id 查，这种情况就不如 rsc 了

不要从技术角度分析这个问题
真相就是 vercel 通过给头部开发者塞钱、塞工作等方式占据了前端技术圈话语权。
dx 之类的只是添头，最终目的就是为了让用的人越来越多，最后框架绑定 vercel 云服务赚钱而已。

现在国外已经有非常大量的 startup 被绑定在 vercel 上大出血了，社区反弹的声音不小。

官方强势啊，有钱，有人，现在的情况下，react = nextjs

@liuqiongyu889 你是如何确定用了 use client 的组件是没有 SEO 的？你有用 Google 的 Search Console 验证过吗？我用最新版 next.js 14 是可以的，而且查看使用 use client 的页面组件的 HTML 源代码也是能看到有做服务端渲染。

如果要实现客户端局部刷新，那么 RSC 里面就只是单纯的获取数据就好了，把真正的页面组件写在 RCC 里面，然后再用 useSWR 的 fallback 属性预先注入来自服务端的数据，后续请求都由 SWR 发起，这样就是和传统的 pages router 一样的效果，既不会损失性能又可以用到 app router 的 layout 功能保持住 layout 部分的状态。（况且我不觉得 RSC 那一定点 JSON 真的会损失多少性能，我们真实上线的用 next.js 做的书单品项目录展示类网站，一页 30 本书籍左右的内容，RSC 在 gzip 之后才不到 5kb ，加上 HTTP2 的长连接，传输 5kb 数据基本可以忽略不计）

生态不太好，我只敢在小项目上用用，大点的是回到 next.js 上了。

@changwei client component 的 page 无法动态内容 SEO ，能 SEO 的部分就是按钮国际化文案之类的固定文本，client component 也会在服务端注水，但是如果数据来自后台 API ，只能用 server component 的 page （页面最顶层一定是 server component ，一定会产生 _rsc 请求）

@changwei 你可以写个 demo 看看能否用 useSWR 实现 /products/123 跳转 /products/456 不产生 _rsc 请求。_rsc 的问题不是数据多大，而是路由跳转肯定会卡顿，无法利用客户端数据做渲染。