作者在专业项目中使用Next.js的App Router和React Server Components一年后，对其核心设计理念提出根本性质疑。尽管许多开发者对Next.js不满，却仍被迫使用。最终作者团队成功将前端迁移至TanStack Start，摆脱了这些设计缺陷。文章从技术角度分析了服务端组件的实际痛点，包括无法乐观更新、每次导航都需重新获取数据等问题。

标题：与Next.js应用路由器共处一年——我们为何选择放弃

核心观点

本文作者基于一年来在专业项目中使用Next.js App Router和React Server Components（RSC）的实践，指出其核心设计存在根本性缺陷，并最终带领团队迁移至TanStack Start框架。以下是关键内容提炼：

一、技术批判：Server Components的致命问题

1. 概念混淆
   RSC将组件分为"Server"和"Client"两类，但命名与传统的"后端/前端"执行环境定义冲突。实际开发中，"Client"组件仍可能在服务端运行，导致理解成本高昂。

2. 开发模式缺陷

   • 乐观更新不可行：服务端渲染的组件无法动态修改，交互逻辑被迫拆分为多个文件（如page.tsx + ClientPage.tsx）。
   • 重复数据请求：每次页面跳转都会强制请求服务端，即使客户端已缓存数据。实验性配置staleTime未被推荐用于生产环境。
   • 布局限制：布局组件无法共享全局状态（如QueryClient），数据请求需重复执行。

3. 性能浪费

   • 双倍数据传输：RSC要求同时发送HTML和JSON格式的组件数据，导致首屏负载翻倍（例如Next.js文档页存在750kB冗余）。
   • Turbopack工具链问题：编译速度慢、错误信息模糊、调试困难（如变量名被篡改为超长字符串）。

二、迁移实践：无缝切换至TanStack Start

1. 渐进式迁移策略

   • 通过Vite配置重定向next引用，逐步替换Next.js API（如实现next/link的适配器）。
   • 保留next/metadata的优秀API，将其简化为独立函数供新框架使用。

2. 收益对比

   • 代码简化：去除RSC的复杂分层后，动态页面逻辑更清晰（如单文件即可处理数据获取与交互）。
   • 性能提升：开发模式构建、生产环境加载速度、页面跳转效率均显著优化。
   • 成本降低：摆脱Vercel的服务器托管依赖，减少带宽浪费。

三、行业反思：选择尊重开发者的工具

1. 框架定位偏差
   Next.js试图兼顾静态网站和动态应用，但两者均非最优解（静态站点推荐Astro/Fresh，动态应用更适合TanStack/Remix）。

2. 生态趋势
   多家企业已从Next.js迁移（如ChatGPT转向Remix），开发者社区对RSC的不满日益显现。TanStack等替代方案因类型安全和开发体验更受青睐。

3. 工具哲学
   作者呼吁支持"尊重开发者"的工具链，并分享自主构建网站生成器的经验，强调精简技术栈带来的效率与幸福感。

附：关键数据与案例

• 冗余请求：预加载路由时，Next.js会发送1.8kB空内容RSC payload，重复引用相同JS块4次。
• 迁移成果：首阶段PR仅需千行新增代码，删除40行，即实现主页功能迁移。
• 行业案例：Superwall公司迁移后CPU使用率大幅下降，验证性能优化空间。

原文链接 | 作者：paperclover | 发布日期：2025年10月21日

以下是评论内容的总结：

对Next.js的批评

1. 状态重置与DOM重载问题

   • 用户抱怨Next.js在加载Server Component时会导致整个页面重新挂载，无法保留状态。
   • 引用：
     • "the entire page re-mounts... it just doesn't preserve state" (skeptrune)
     • "all hooks (useState) will reset slightly after the request completes" (sktrdie)

2. 复杂性与过度设计

   • 许多用户认为Next.js过于复杂，尤其是App Router和RSC（Server Components）的设计。
   • 引用：
     • "Next is a pile of confusing mess... a conceptual mess of initialisms" (gherkinnn)
     • "so many layers of abstraction that are simply not necessary" (adverbly)

3. 性能与开发体验问题

   • 部分用户提到切换到其他方案（如Vite + React Router）后性能显著提升。
   • 引用：
     • "replaced next.js with a simple router... everything got simpler, and FASTER" (sibeliuss)
     • "pagespeed, hosting costs... all took a significant hit" (Zaheer)

对Next.js的辩护

1. 命名与设计合理性

   • 有用户认为RSC的命名和设计是经过深思熟虑的，尽管存在争议。
   • 引用：
     • "it's a complex issue that requires lots more thought" (sktrdie)

2. 功能与灵活性

   • 部分开发者表示Next.js在满足复杂需求时表现良好，但需要深入理解。
   • 引用：
     • "I'm just a Next.js developer... and am quite happy with it" (sktrdie)

其他观点

1. 回归简单框架

   • 一些用户建议使用更简单的工具（如Vite、Django或Rails），避免过度依赖复杂框架。
   • 引用：
     • "just not use server components" (383toast)
     • "replacing that crazy thing... with steady frameworks like Rails" (mosselman)

2. 行业趋势反思

   • 评论指出前端框架过度追求创新，忽视了已有解决方案的成熟性。
   • 引用：
     • "frameworks have continually re-solved problems... already solved in something other than Javascript" (zenethian)
     • "everyone's optimizing for blog post metrics, not actual problems" (sanskarix)

总结

评论中既有对Next.js的强烈批评（尤其是状态管理、复杂性和性能问题），也有对其设计合理性的辩护。许多用户倾向于更简单的替代方案，并反思了前端框架过度设计的行业现象。