说几点个人使用 nextjs 的感受

[MorningStar0]

网页： https://freezer-home.ashesborn.cloud/ 仓库： https://github.com/sadofriod/freezer-home

部署角度

目前体验基本满分。结合 vercel 基本不用任何配置，就能快速部署。并且使用 cloudflare 的域名后，也可以实现让国内访问。

开发体验角度

无法在 server component 里直接使用 hooks ，ref 和 react 的事件收集（ onChange 这类）的功能，所以有些动画需要原生实现，失去了 react 的很多便利性。

SEO 角度

由于可以将大部分内容直接通过静态页面返回，所以确实带来了巨大的提升。但是官方文档对于 robots ，sitemap ，meta 标签的 keywords 之类的常见功能没有提供一个比较好的解决方案(目前还是采用字符串模版拼接的方式，或者是我没仔细看)，理想的情况下希望能提供几个函数来收集每个路由下的信息来解决这个问题。

监控工具的集成角度

目前我集成了 google analytics 、tag manager 、google 站长工具。官方提供了一个集成的 component 配置比较简单。

server 负载角度

对于大部分网页访问量不高的情况不会有问题，但虽然提供了 server component 的渲染缓存，但对于接入数据的变动 server component 来说，还是存在部分 CPU 密集型的计算在 nodejs 的 server 中，在访问量比较大的时候，还是需要考虑。

总结

总的来说，对于我个人来讲，如果没有强烈的 SEO 需求，对于一般项目的话不会采用 nextjs 。server component 和 client component 的分离，迫使我在状态管理上要做更多思考和操作。而且对于首屏的渲染在现在协商缓存的基础下，也只有用户收到新版本的网页的时候会有差距，其他大部分情况下差距不大。

[zhwithsweet]

@zhwithsweet #20 地址 [f3-app]( https://github.com/fisand/f3-app)

[MorningStar0]

https://sadofriod.github.io/

[luvsic]

@zhengfan2016 #18
我也觉得 Next.js App router 的心智负担大，https://qwik.dev/ 的代码更好理解

[Plumbiu]

@zhengfan2016 我觉得你也有误解，客户端和服务端是不能传递函数，不是不能传递 JSX ，你话说的范围缩小了

[yeluowjz]

@cwliang 解析富文本的 json 数据，递归生成节点树的时候，图片类型用了 Image 组件，结果就内存泄漏了

[zhengfan2016]

@Plumbiu 你说得对，确实是不能传递函数，这个我打错了

[ZZ74]

@zhengfan2016 和 jsp 一样的.... 好不好用看项目。但是 jsp 被淘汰也是值得吸取的教训

[fyxtc]

我去年用 13 写了个项目，然后今年又用 15 写了个项目，重新看 app router 概念，刚看的那时觉得很恶心，为什么变化这么大，用过了其实就还好。还有就是 server 里用 client hooks 很容易，直接把变化的部分抽成 client 就好了。整体来说新版适应后还是更舒服，数据交互写起来爽很多，不用像 13 一样到处都是 swr 和判断 loading ，直接在 server 里 db 出来就好了，用过了就回不去了

[zhjrcc]

感觉 OP 这种贴真挺好的，有经验的前辈可以讨论，然后我们有一些在学习的也能从你们的讨论中得到一些知识~~

[SkywalkerJi]

@lavard 现在对 ai 适配最好的就是 next 吗

[shiny]

sitemap.xml 、robots.txt 、meta 自带了一些方案，如 generateSitemaps, generateMetadata, robots.ts ，我感觉还挺好用的

[OneNewLife]

12 以前我给满分，从 13 开始一直是负增长。。。

[XTTX]

用 1.5 年的经验去评价别人对一个栈的理解业余， 这事本身就很业余。
1. 是不是真的快
2. 快多少
3. 服务器需要增加多少费用
4. 增加的心智负担
5. 增加的复杂程度
6. 增加的接手成本

这是取舍题。

sitemap, OG gen, meta 都有不用 ssr 的方案， 而且 SEO 早就不是问题了，2024 了 google 也不至于这么落后。

[gogozs]

如果公司组织架构本身就前后端分离，你用 rsc 也没多大意义，一个接口请求慢，你这边本身也做不了什么事情。如果在 layout 做 rsc ，rsc 调接口，甚至每个页面返回都变慢。

如果全栈，那接口慢就自己直接改造了，那还是很爽的。关键还是你得按照 next js 想要的方式写就很爽，如果还是前后端分离，那是自己给自己找麻烦。

再补充一个点，router.push 后，useSearchParam() 更新还得过一次服务端，然后客户端组件就会可能用到旧参数渲染。

[MorningStar0]

@shiny 我看了官方的这些例子，正如我描述的，这种维护字符串模版的模式还是没有达到我的预期。如果能自动通过路由收集生成 sitemap ，然后类似用‘use client’或者注释的方式来提供 robots 和 meta ，这是我希望它能达到的效果。

[XCFOX]

React Server Component 在我看来不是一个好的设计，为了解决一个简单问题的问题引入了更多概念和复杂度。

最初 RSC 要解决的简单问题是：在服务端渲染时如何请求数据？
由于 React hooks 令人费解的设计哲学，React 传统组件无法异步。在客户端渲染时，一般通过 `useEffect` 来获取数据。而在服务端渲染时，我们无法使用 `useEffect`，这使得在服务端请求数据（以及其他异步操作）成为了一个问题。顺带一提，vue3(nuxt.js) 就不会面临这个问题，因为 vue3 的组合式 API 没有 React hooks 的一堆限制，并且 setup 是能够异步的。

Next.js(RSC)给出的答案是：设计一个全新的服务端组件，专门用来在服务端发请求。好处是，这个组件可以异步了，坏处是，在这个组件中无法使用 hooks 。
Remix(React-Router-v7)的答案是：Loader 。预先定义好要加载的数据，框架会在数据加载完后将数据注入到组件中。

在我看来 Loader 方案明显比 RSC 更好：

1. 性能更好：Loader 单次加载完成页面所有数据； RSC 每次加载一个组件，加载完父组件的数据，再加载子组件的数据。
2. 更低的心智负担：Loader 只需要提前写好请求，然后方便地通过 useLoaderData 拿到数据； RSC 则引入了额外的服务端组件的概念，在编写时得区分是否为服务端组件，还得到处写 "use client"。

包括新出的 TanStack 也是提倡使用 Loader 方案而不是 RSC 。

参考：
https://react.dev/blog/2020/12/21/data-fetching-with-react-server-components
https://nuxt.com/docs/getting-started/data-fetching
https://remix.run/docs/en/main/discussion/data-flow
https://tanstack.com/router/latest/docs/framework/react/guide/data-loading

[XTTX]

@MorningStar0 sitemap 生成自己写 https://github.com/supabase/supabase/blob/master/apps/www/internals/generate-sitemap.mjs 每个网站的需求都不一样， 很多需要读 mdx ， 有些 url 又需要过滤掉。package.json 里 写个 postbuild, 指向这个 script 就行了。

[MHPSY]

@XCFOX 点赞了，你的想法跟我几乎一摸一样，我也写过 nuxt next remix

next 我最不想去适应的一点就是 hook 不能写在服务端组件里面。

nuxt 就很正常，useFetch 常规情况下都很好用

remix 更不用说了，几乎是命令式的请求，也不用操心那么多东西，甚至是服务端为主。