搜索
  • 谈谈你使用 nextjs 的感受
  • 发布于 1周前
  • 77 热度
    8 评论

个人使用nextjs有一段时间了，基本感受如下：

部署角度

目前体验基本满分。结合 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 的分离，迫使我在状态管理上要做更多思考和操作。而且对于首屏的渲染在现在协商缓存的基础下，也只有用户收到新版本的网页的时候会有差距，其他大部分情况下差距不大。
用户评论
  • 叶舞翩翩
  • 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
  • 2024/12/21 10:59:00 [ 0 ] [ 0 ] 回复
  • 旧巷
  • 用 1.5 年的经验去评价别人对一个栈的理解业余， 这事本身就很业余。
    1. 是不是真的快
    2. 快多少
    3. 服务器需要增加多少费用
    4. 增加的心智负担
    5. 增加的复杂程度
    6. 增加的接手成本
    这是取舍题。
    sitemap, OG gen, meta 都有不用 ssr 的方案， 而且 SEO 早就不是问题了，2024 了 google 也不至于这么落后。

  • 2024/12/21 10:58:00 [ 0 ] [ 0 ] 回复
  • 一滴水墨
  • 我去年用 13 写了个项目，然后今年又用 15 写了个项目，重新看 app router 概念，刚看的那时觉得很恶心，为什么变化这么大，用过了其实就还好。还有就是 server 里用 client hooks 很容易，直接把变化的部分抽成 client 就好了。整体来说新版适应后还是更舒服，数据交互写起来爽很多，不用像 13 一样到处都是 swr 和判断 loading ，直接在 server 里 db 出来就好了，用过了就回不去了。
  • 2024/12/21 10:58:00 [ 0 ] [ 0 ] 回复
  • 森屿微央
  • 公司主用框架就是 nextjs ，实话说我觉得 op 对 nextjs 很大概率仅存于业余上的使用或者就不是专业的 react 前端，才能得出 server component 不好用的结论。server 组件优势就是可以把一些内容移到水合前就填充进白纸 html 里，加快首屏渲染速度。至于 hooks ，你完全可以分离拆组件，而且 nextjs 允许你客户端和服务端组件相互嵌套，你只要不通过 props 传递 JSX 就可以，其实是有一丢丢像 astro 的岛，每个客户端组件就是一个岛

    推荐阅读国外其他前端 er 对 react 服务端的帖子： https://www.joshwcomeau.com/react/server-components/
    我是工作经验 1.5 年的 react 前端，如果你工作年限比我大，那么你说得对
  • 2024/12/21 10:57:00 [ 0 ] [ 0 ] 回复
  • 可悲笑话
  • 用过一段时间，体验不是很舒服，如果不考虑 SEO ，我是不会用这玩意的。
    13=>14=>15 每个版本变动很大，需要重新看文档。文档比较杂，同一个东西能看到好几种使用姿势。还有那个 NextAuth ，简直就是一坨。跑起来很吃内存，如果有内存泄漏问题，需要很强的 node.js 功底去排查，用起来成本挺高的
  • 2024/12/21 10:56:00 [ 0 ] [ 0 ] 回复
  • 与何人说
  • 我是 SRE ，目前也刚刚开始自学 React 和 Next.js ，现在有个问题想请教下，React Next.js 开发时是需要明确区分服务端组件还是客户端组件吗？这些一般都是在设计的时候根据数据情况来进行区分吗？
  • 2024/12/21 10:56:00 [ 0 ] [ 0 ] 回复
  • 浪迹消磨
  • 开发体验确实不太行，热更新慢而且老报错。如果不是考虑 SSR 还是用 Vite 开发舒服，生态完全可以自己选择，Vite + tailwindcss + shadcn/u,或者 Vite + mui or antd+ styled-compoents 都不错！
  • 2024/12/21 10:56:00 [ 0 ] [ 0 ] 回复
  • 隔窗看你
  • 生态为王，nextjs + tailwindcss + shadcn/ui 这套太能打了，太适合目前的 AI 时代了，很多产品只要描述下就能生成。就是 React 19 大改了， 很多第三方库还没跟上，用 next15 又上 React 19 又有点尴尬 ， 开发体验还没那么快升上去，等周边生态吧。
  • 2024/12/21 8:19:00 [ 0 ] [ 0 ] 回复
可能感兴趣的话题