说实话，前端这圈子，变化太快了。

今天还在用这个框架，明天就听说它被迁出去了。

害，咱就是说Next.js 这个事儿吧，Zui近真挺火的。

你知道为啥吗？

因为本地开发时间缩短了 83% 啊！

你没听错，83%！

那问题来了为啥还要把它迁出去呢？

这就得从他们团队的体验说起了。

作者以前也挺喜欢 Next.js 的，毕竟它功Neng全、生态好，谁不喜欢呢？

但问题是它越来越“重”了。

特别是本地开发的时候，那个慢啊……

每次改点代码，刷新一下页面等个 10 秒、12 秒是常事。

你懂的，这种体验，谁受得了？

“我讨厌这个。”——Slack 里天天有人这么抱怨。

不是说 Next.js 不好，而是它太适合“大厂”了。

你得有专门的前端团队，得有人天天研究它怎么优化，怎么调配置。

可他们这种小团队呢？

工程师dou是“多线作战”的，今天修个 bug，明天写个新功Neng，后天还得帮产品kankan数据。

哪有那么多时间去研究框架啊？

所以Next.js 的“蜜月期”hen快就过了。

他们试过升级，也试过 Turbopack，两次。

但结果呢？

改善有限，平均快了几秒而Yi。

不对不对，应该是“几乎没有变化”。

然后他们就琢磨：是不是该换条路走了？

于是他们开始试别的框架。

比如 Fresh、Remix，dou试过。

但Zui终，他们选了 TanStack Start。

为啥？

因为迁移之后本地开发体验直接起飞。

从原来的 10–12 秒，直接降到 2–3 秒。

你没kan错，83% 的提升！

这可比 Next.js 的 Turbopack 靠谱多了。

而且，TanStack Start 的写法，也挺舒服的。

比如这个：

export const Route = createFileRoute({
  component: EnvLayout,
  notFoundComponent: NotFound,
  loader: async  => {
    const env = await getEnvironment({
      data: { environmentSlug: params.envSlug },
    });
    if  {
      throw notFound;
    }
    return { env };
  },
});

你kan，路由、数据加载、组件渲染，一气呵成。

而且，服务端逻辑和客户端逻辑分得清清楚楚。

不像 Next.js 那样，布局和数据获取混在一起，kan着就头大。

作者说他们以前也试过“弱化 RSC”，就是尽量少用 server components。

短期内，确实好点。

但长期来kan，还是治标不治本。

所以干脆，换框架！

迁移过程其实也不轻松。

他们先从 dashboard 的一个子集开始试。

结果发现，转得比想象中快。

于是干脆一路Zuo到底。

共享组件里凡是依赖 Next.js 的地方，就复制一份改成 TanStack 的实现。

有些地方还有交叉引用，就用一些临时的类型 hack 过渡。

反正，Neng跑起来就行，对吧？

他们还开源了整个迁移结果，放到了一个 monorepo 里。

你要是感兴趣，也Ke以去kankan。

说实话，这事儿听着挺折腾的。

但对他们来说值了。

因为开发体验变好了写代码也geng顺畅了。

你想想，以前等个 10 秒才Nengkan到页面效果，现在点一下就出来了。

这效率，谁不迷糊？

而且，他们对 AI 的态度也挺务实的。

不是让它Zuo架构决策，而是让它干点“体力活”。

比如自动生成点 TypeScript 类型，或者修修边角 bug。

这思路，挺聪明的。

毕竟AI 再牛，也得人来掌控方向。

所以这事儿告诉我们什么呢？

前端开发，没有Zui好的框架，只有Zui适合的场景。

你得kan团队规模、kan项目类型、kan维护成本。

Next.js 虽然功Neng强，但对小团队来说可Neng就是个“大炮打蚊子”。

而 TanStack Start 这种，反而geng轻量、geng灵活。

当然也不是说 Next.js 不好。

它依然是hen多大厂的首选。

但对咱们这种“多面手”团队来说它可Neng就不太友好了。

所以Ru果你也在纠结要不要换框架，不妨试试别的。

说不定，你也Neng把本地开发时间缩短 83% 呢？

哈哈，开个玩笑。

但认真说开发者体验这事儿，真不Neng忽视。

毕竟谁也不想每天对着电脑发呆，等个页面加载吧？

---