2025 快过完了，有 ssr 需求的项目现在最佳选择是什么？

[asen001]

之前用过 nextjs app router 体验一坨，热更新很慢，很吃内存，而且 "use server" "use client" 开发起来挺麻烦，写到后面直接 全部 "use client"。

react router v7 怎么样，有人用过吗，求分享，接了个小活不想花时间踩坑。

项目做完了前来汇报一下。

最终斗胆选择了 tanstack start ，已上线，体验挺好。部署使用 docker 也很方便，nitro 直接输出的 .output 复制进去就能用了，我依赖了 sharp 做图片处理，把 sharp 排除后手动在镜像构建阶段安装就能用了。

唯一踩坑，server function 中引用包含 getRequest() 的函数，没有使用 createServerOnlyFn 包装，导致客户端意外引入服务端代码，报了完全无关的错误出来，文档中也没有提到。检查了很久代码都没找到问题，最后翻阅 github issues 才知道是 getRequest() 带来的 boundary leak ，浪费一个下午时间。

[DICK23]

tanstack start

[zhengfan2016]

我觉得 nextjs 还好吧，我是基本按照下面的去拆封的，一般 page 就放一个骨架，然后剩下的按功能拆

- common // 公共业务组件
-- navbar.tsx
-- sidebar.tsx
- list.tsx // client 的 list 页
- page.tsx// 页面骨架

page route 时代过来不适应很正常

[nnccree]

react router 我的个人项目在用，开发体验挺好的
我也不太喜欢 nextjs 的 use server, use client 的繁文缛节

[plumk]

强烈推荐 nextjs app router 模式配合 server action ，连 api 都不用写了

[codehz]

nextjs 那玩意是 rsc ，不是 ssr 。。。这俩玩意看着类似实际差异巨大

[zy445566]

next.js 在没有 Ai 前 我是觉得这个代码设计和框架还挺丑陋的 但是有 Ai 后 我觉得它是 Ai 最友好的框架 目前没有碰到敌手 不需要切换前端和后端 基本几句话 整个项目都可以用 Ai 搭起来 而且它目前也算是最方便用 Ai 修改功能的框架 说个功能前后端直接干了 它感觉是运气好恰好踩中风口了😎

其它框架感觉用 Ai 写没有 next.js 那么顺 要么切前后端 Ai 理解业务难度还是要比使用 next.js 高不少

[asen001]

@zy445566 区别大吗，我用 AI 写 vue react 普通的 vite 项目都感觉还行啊，nextjs 有什么和 AI 更契合的地方呢？仅仅是前端和后端能写在一起？

[avenger]

Next.js 16 刚发布，开发速度快了很多

[XCFOX]

从 Remix 用到 React Router v7 ，非常好，生产环境跑得很稳。

小项目用过 Next.js ，跟 React Router v7 比完全是倒退：
- Next 用 "use server", "use client" 区分服务端组件和客户端组件，React Router v7 用 .server.jsx 和 .client.jsx 区分服务端组件和客户端组件，React Router 正常太多了；
- Next 的打包器 Turbopack 比 Vite 慢太多了，开发体验严重倒退；
- Remix 提出的 loader 比 RSC 好用一百倍，获取数据纯函数就行了，RSC 非得和视图耦合在一起，RSC 还有一堆限制，完全不是正常的 React 组件；

[Immortal]

Astro?

[asen001]

@Immortal 这个感觉更适合静态为主的网站

[an1ig]

@DICK23 #1 +1 ，开发体验比 nextjs 好多了

[stimw]

最近两年没写过前端了，rsc 不在 vercel 部署还有什么特别的好处吗？一直觉得这玩意有点鸡肋。

[laoona]

试试这个： https://doc.ssr-fc.com/

[zy445566]

@asen001 #7
功能不分前后端，一起的话，可以直接完成功能。你可能主要是写前端，我主要是项目为主，前后端都要自己搞，之前是 nest.js+react 两个项目分开，很多时候后端的(nest.js)完成度就不太好(瞎写大量无效代码，就算正确，前端接口也需要我去改)，或者说如果单抽一个 Ai 不知道怎么去做一个完整的功能，但是使用 next.js ，AI 本身也可以把前后端都考虑进去，接口和页面都一起完成，上下文多了很多，就能更好实现功能，我体验下来效果至少是前后端分开的 10 倍有余，尤其是后端的代码编写。

当然如果仅仅是前端开发，不需要自己写后端倒还好。

[rocmax]

rsc 要比传统的 ssr 超前一些，主要是在组件层面将静态部分和动态部分分开渲染。而 ssr 只是强调服务器可以直接返回 HTML ，如果你只有 SEO 方面的需求就没必要上 rsc 。这两者之间的区别就是客户端的 js 文件大小和静态部分需不需要 hydrate ，需要更加极致客户端体验的话就用 rsc 。
其实 nuxt ，astro ，tanstack start 等各家都在搞 Partial Hydration 。处理服务器和客户端边界的时候都有类似的操作，要么用指令，要么用特定函数名，要么分离文件，本质是一样的。不存在 use server/client 比较复杂的问题，毕竟执行环境不一样，不这么限制不行。

[bbbblue]

写到后面全部 use client 可还行 😂
一般最外层的 page 还保持 server component 用来获取需要的数据 里面需要交互的组件抽出来 有点像 remix 的 loader 用法

不过 nextjs16 又多了一个 use cache 强制 dynamic content 必须 use cache 或者被 Suspense 这点改动其实挺好的 但用起来有点难受 特别是有 path params 的时候。。
哎 蛋疼

[JiRouWaZi]

@zy445566 怎么不说 jsp 、php, 历史代码语料多, 顺利的一批； nextjs ，团队就有问题，不值得使用他们的

[zaneliu]

@Immortal +1

[tabc2tgacd]

有 ssr 需求的，我仍然继续 express+nunjucks ，这个组合还是挺好用的。

[hutoer]

astro +1

[clarkethan]

@DICK23 +1 ，tanstack 家的产品都很好用

[est]

只会 astro 的路过。

[ttys000]

Rails

[zhongchunfeng]

nextjs 生态好 ai 支持非常友好

[Dyon]

use client 是 rsc 的标准，跟 next 本身无关，不想用你直接就在顶层写一个 use client 不就好了
https://reactrouter.com/how-to/react-server-components

[Whbbit1999]

nitro 构建出来的东西部署是真的方便