与 Next.js 应用路由器共度的岁月——为何我们选择转型

对 React 服务器组件与 Next.js 15 的批判性思考

在为雇主开发网页应用时，我持续使用Next.js进行专业开发，但其核心设计的应用路由器和React服务器组件 (RSC)令我深感挫败。问题并非出在小漏洞或API混乱上，而是对Vercel和React团队在构建过程中做出的根本性设计决策存在重大分歧。

参加的Web开发活动越多，越发现许多人虽厌恶Next.js却仍被迫使用。本文将分享我和同事如何逃离这个地狱，将整个前端无缝迁移至TanStack Start。

目录：

• 技术回顾：什么是服务器端组件？
• 应用路由器的实际陷阱
  • 乐观更新不可行
  • 每次导航都是额外请求
  • 布局存在人为限制
  • 你仍需重复下载所有内容两次
  • Turbopack 糟透了
• 工作中无缝弃用 Next.js 和 Vercel
  • next/metadata 非常出色
  • next/og 也相当不错
• 我的体验感觉很平常
• 选择尊重你的工具

技术解析：什么是服务器组件？§

RSC的核心理念是将组件划分为两类： “服务器” 组件与 “客户端” 组件。服务器组件不包含useState、useEffect等功能，但可采用async function形式，并能直接调用数据库等后端工具。客户端组件延续现有模式：后端代码生成HTML文本，前端代码通过window.document.*管理DOM。

首个灾难：命名混乱！！React现在用 “服务器” 和 “客户端” 指代特定概念，完全无视其既有定义。问题在于—— 客户端 组件同样能在后端运行！本文将采用 “后端” 和 “前端” 术语描述Web应用的两大运行环境：分别对应Node.js进程与Web浏览器。

这种 服务器/客户端 组件模型颇具巧思。由于<Suspense />等内置组件会经网络序列化传输，数据获取可通过异步 服务器组件 实现极简建模，而回退界面则呈现出客户端般的交互体验。

src/app/\[username\]/page.tsx

// For this article, server components will be highlighted in red
export default async function Page({ params }) {
    // Page params are given as a resolved promise
    const { username } = await params;

    // The components `UserInfo` and `UserPostList` will be run at the same
    // time. Once `UserInfo` is ready, the visitor will see the page with a
    // `PostListSkeleton` if the post list is not yet ready.
    return <main>
        <UserInfo username={username} />

        <Suspense fallback={<PostListSkeleton />}>
            <UserPostList username={username} />
        </Suspense>
    </main>
}

// Waterfalls are avoided by having multiple components, which
// are all evaluated at the same time.

async function UserInfo({ username }) {
    const user = await fetchUserInfo(username);
    return <>
        <h1>{user.displayName}</h1>
        {user.bio ? <Markdown content={user.bio} /> : ""}
    </>
}

async function UserPostList({ username }) {
    const posts = await fetchUserPostList(username);
    return /* post list ui omitted for brevity */;
}

若忽略 React 本身 40kB 的 gzip 打包大小，上述示例中 UI 与数据获取完全无需 JavaScript 代码——它仅需流式传输标记！例如，<Markdown />组件内部的假想Markdown解析器始终驻留在后端。当需要交互式前端时，只需在以“use client”开头的文件中创建 客户端组件 即可。

src/components/CopyButton.tsx

"use client"; // This comment marks the file for client-side bundling.

export function CopyButton({ url }) {
    return <>
        <span>{url}</span>
        <button onClick={() => {
            const full = new URL(url, location.href);
            navigator.clipboard.writeText(full.href);
            // omitting error handling, success ui, styles
        }}>copy</button>
    </>
}

src/app/q+a/Card.tsx

export function Card() {
    return <article>
        <header>
            {/* Make the browser import the copy button */}
            <CopyButton url="/q+a/2506010139" />
        </header>
        <p>
            {/* Process markdown on the backend */}
            <Markdown content=".........." />
        </p>
    </article>
}

应用路由器的实际陷阱§

在退出Bun运行时工程师岗位后(我曾实现服务器组件打包和RSC模板)， 我加入了一家小型公司，参与前端开发：基于Next.js构建的应用程序，后端采用Hono框架。以下笔记是我在维护和开发新功能时，针对实际问题进行的简化总结。所有这些问题导致团队成员的时间被浪费在两件事上：要么绕过设计缺陷，要么互相解释为何本应无关紧要的问题却成了无法撼动的障碍。

乐观更新不可行§

Next.js 文档在说明执行突变操作时未提及乐观更新；似乎未考虑此场景。由 React服务器 渲染的组件，按设计在挂载后不可修改。可能变更的元素需置于客户端组件中，但客户端组件无法进行数据获取——即使在后端SSR过程中亦然。这导致服务器端组件功能极其有限，仅负责数据获取，而客户端组件则包含页面的大部分静态内容。

src/app/user/\[username\]/page.tsx

export default async function Page() {
    const user = await fetchUserInfo(username);
    return <ProfileLayout>
        <UserProfile user={user} />
    </ProfileLayout>;
}

src/app/user/\[username\]/UserProfile.tsx

"use client"; // Must separate the client code into a second file!

export function UserProfile({ user: initialUser }) {
    // There are many great state management libraries out there;
    // for simplicity, this example will use one state cell.
    const [user, optimisticUpdateUser] = useState(initialUser);

    async function onEdit(newUser) {
        optimisticUpdateUser(newUser);
        const resp = await fetch("...", {
            method: 'POST',
            body: JSON.stringify(newUser),
            ... // (headers, credentials, tracing, and more)
        })
        if (!resp.ok) /* always remember to test for errors! */
    }

    return <main>{/* user interface with editable fields... */}</main>:
}

随着页面交互需求增加，试图将静态部分完全保留在服务器端变得越来越混乱。在工作应用中，几乎每个 UI 元素都会显示动态数据。通过 WebSocket 可实时同步更新数据(例如用户卡片中的在线状态及其基本资料)。由于此类组件架构难以让工程师理解和维护，我们几乎所有页面都完全采用“use client”模式，通过page.tsx定义数据获取逻辑。

以下是实际应用中更具体的示例，展示我们工作中使用的数据获取库TanStack Query。

src/queries/users.ts

// At work, there is a helper function `defineQuery` for type safety.
// Fetchers are trivial and can run on the backend or the frontend.
export const queryUserInfo = (username) => ({
    queryKey: ['user', username],
    queryFn: async ({ ... }) => /* fetch data */
});

src/app/user/\[username\]/page.tsx

export default async function Page({ params }) {
    const { username } = await params; 

    // There's no global state in the React Server. Since layouts 
    // are executed in parallel, the TanStack `QueryClient` has to
    // be reconstructed multiple times per route.
    const queryClient = new QueryClient();
    await queryClient.ensureQueryData(queryUserInfo(username));

    // HydrationBoundary is a client component that passes JSON
    // data from the React server to the client component.
    return <HydrationBoundary state={dehydrate(queryClient)}>
        <ClientPage />
    </HydrationBoundary>;
}

src/app/user/\[username\]/ClientPage.tsx

"use client";
export function ClientPage() {
    const { username } = useParams();
    const { data: user } = useSuspenseQuery(queryUserInfo(username));

    // ... some hooks 

    return <main>
        {/* ... an interactive web page */}
    </main>;
}

此示例必须拆分为三个独立文件，这是由于服务器端组件打包规则所致(客户端组件需要“use client”声明，且服务器端组件文件常因仅限服务端的导入语句而无法在客户端被引入)。若采用Pages路由方案，由于getStaticProps和getServerSideProps具备树摇功能，本可整合为单一文件。

每次导航都是另一次数据获取§

由于应用路由器将每个页面初始化为服务器端组件(理想情况下仅包含小范围交互区域)，因此跳转至新页面时，无论客户端已拥有何种数据，都必须重新从Next.js服务器获取内容！即使存在loading.tsx文件，当用户打开/页面、跳转至/other再返回/时，系统仍会显示加载状态并重新获取首页内容。

唯一例外是 纯静态内容 场景，此时即时跳转和预加载效果极佳。但 Web应用并非静态 ，它们包含大量动态内容。登录状态会影响首页显示——这种情况令人抓狂，因为客户端明明拥有即时呈现页面的全部资源，却因cookie未更新而无法刷新。

附注 ：在空白项目进一步测试中，我观察到Next前端代码会预加载路由，但 完全不包含实际内容 。在Hello World示例中，这段1.8KB的RSC有效负载竟指向两个不同的JS代码块，且重复调用四次。这纯粹是带宽和出站流量的浪费——尤其考虑到点击链接时所有数据都会被重新加载。

1:"$Sreact.fragment"
2:I[39756,["/_next/static/chunks/ff1a16fafef87110.js","/_next/static/chunks/7dd66bdf8a7e5707.js"],"default"]
3:I[37457,["/_next/static/chunks/ff1a16fafef87110.js","/_next/static/chunks/7dd66bdf8a7e5707.js"],"default"]
4:I[97367,["/_next/static/chunks/ff1a16fafef87110.js","/_next/static/chunks/7dd66bdf8a7e5707.js"],"ViewportBoundary"]
6:I[97367,["/_next/static/chunks/ff1a16fafef87110.js","/_next/static/chunks/7dd66bdf8a7e5707.js"],"MetadataBoundary"]
7:"$Sreact.suspense"
0:{"b":"TdwnOXsfOJapNex_HjHGt","f":[["children","other",["other",{"children":["__PAGE__",{}]}],["other",["$","$1","c",{"children":[null,["$","$L2",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L3",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]]}],{"children":null},[["$","div","l",{"children":"loading..."}],[],[]],false],["$","$1","h",{"children":[null,["$","$1","KCFxAJdIDH3BlYXAHsbcVv",{"children":[["$","$L4",null,{"children":"$L5"}],["$","meta",null,{"name":"next-size-adjust","content":""}]]}],["$","$L6","KCFxAJdIDH3BlYXAHsbcVm",{"children":["$","div",null,{"hidden":true,"children":["$","$7",null,{"fallback":null,"children":"$L8"}]}]}]]}],false]],"S":false}
5:[["$","meta","0",{"charSet":"utf-8"}],["$","meta","1",{"name":"viewport","content":"width=device-width, initial-scale=1"}]]
9:I[27201,["/_next/static/chunks/ff1a16fafef87110.js","/_next/static/chunks/7dd66bdf8a7e5707.js"],"IconMark"]
8:[["$","title","0",{"children":"Create Next App"}],["$","meta","1",{"name":"description","content":"Generated by create next app"}],["$","link","2",{"rel":"icon","href":"/favicon.ico?favicon.0b3bf435.ico","sizes":"256x256","type":"image/x-icon"}],["$","$L9","3",{}]]

经审查发现其中实际存在内容：加载状态。你注意到了吗？

["$","div","l",{"children":"loading..."}]

这种浪费依然严重，因为所有数据都会在实际页面的RSC中重新输出。

解决方法似乎是使用staleTime，但该功能标记为实验性且“不推荐用于生产环境”。这种非默认的补丁式配置选项实在令人尴尬。即便启用该功能，也无法让多个引用相同底层数据的页面共享数据。

App Router无法处理的加载状态场景是：当用户在类似Git项目问题页面的界面点击用户名跳转至个人主页时。使用loading.tsx时整个页面仅为骨架结构，但若通过TanStack Query建模此类查询，即可在用户资料和仓库数据加载期间即时显示用户名和头像。服务器端组件无法支持此类导航，因为数据仅存在于渲染组件中，故需重新获取。

在我们的Next.js站点中，服务器端数据获取器添加了以下代码行，通过跳过数据获取阶段来加速软导航：

src/util/tanstack-query-helpers.server.ts

export function serverSidePrefetchQueries(queries) {
    if ((await headers()).get("next-url")) {
        // This is a soft-navigation. SKIP the prefetching to make it faster.
        // The client might already have this data, and if not, they have the
        // loading state. Ideally, this server request wouldn't exist -- The
        // client side has nearly ALL the code since the app is written mostly
        // as client components. Kind of a design flaw of the App router TBH.
        return;
    }
    // ... data prefetching-logic ...
}

此外，loading.tsx 文件应包含 useQuery 调用，这样在加载空 RSC 的网络请求期间，若实际需要数据，系统会同步进行数据获取。实际上，loading.tsx 的状态可以直接作为客户端组件本身，此时您将看到客户端页面。

src/app/user/\[username\]/loading.tsx

"use client";
export default function PageLoadingSkeleton() {
    return <ClientPage />;
}

在工作中，我们仅让 loading.tsx 文件包含 useQuery 调用并显示骨架界面。这是因为当 Next.js 加载实际服务器组件时，无论如何都会导致整个页面重新挂载。此时不会进行虚拟 DOM 差异比较，意味着所有钩子(useState)在请求完成后都会略微重置。我曾尝试复现一个简单场景，迫使 Next.js 仅更新现有 DOM 并保留状态，但始终未能实现。所幸空白 RSC 调用的耗时足够短暂。

布局的人为限制§

布局组件虽能执行数据获取，却无法以任何形式观察或修改请求。此设计使Next.js能随时获取并缓存布局组件。而在其他框架中，布局组件与页面组件并无功能差异，本质上都是普通组件。

独立获取布局组件的构想虽巧妙，却因其意味着每次布局加载都需重新获取数据而显得荒谬。你无法共享QueryClient，只能依赖其猴子补丁化的fetch来实现承诺的相同GET请求缓存。

当同事问我为何Next.js会拒绝某些代码时，我已放弃解释技术细节，直接说：“这是Next.js的技能问题，我很快就会搞定它，别担心。”这些规则对普通开发者而言实在难以理解。

你依然会重复下载所有内容§

与“Islands Architecture”不同，服务器组件仍需在前端进行水化处理以支持Suspense并保留客户端组件状态。进行软导航时，“RSC有效负载”(完全不属于HTML)会通过fetch获取。在新页面加载时，HTML 用于实现 首次绘制，但该 HTML 不包含客户端组件和 Suspense 的相关信息。React 的解决方案是 发送整个页面的标记代码副本 。Next.js 生产服务器在动态页面渲染时发送的内容示例如下：

GET /user/clover

<!DOCTYPE html>
<html>
<head>
    {link and meta tags}
</head>
<body>
    {server side render}
    <script>
        // a bootstrap script that sets up global `__next_f` as
        // an array. once React loads, this `.push` function
        // gets overwritten to write new chunks directly to the
        // RSC decoder. this script has some dom helpers too
        (self.__next_f=self.__next_f||[]).push([0])
    </script>
    <script>
        // the RSC payload for the application shell.
        self.__next_f.push([1,"1:\"$Sreact.fragment\"\n2:I[658993,[\"/_next/st{...}"])
    </script>

    <!--
        the closing </body> is NOT written yet, since there is a
        suspense boundary not resolved. time passes, and only
        then is more data is written
    -->
    <div class="user-post-list">
        {server side render of a Suspense boundary}
    </div>
    <script>
        // the RSC payload for the suspense boundary
        self.__next_f.push([2,"14:[\"$\",\"div\",null,{\"children\":[[\"$\",\"h4\"{...}"])
    </script>
    
    <!-- HTML and script tags repeat until the entire page is done -->
</body>
</html>

该方案导致 初始HTML负载体积翻倍 。更糟的是，RSC负载包含用JS字符串字面量引用的JSON数据，这种格式远不如HTML高效。虽然brotli压缩效果良好且浏览器渲染速度快，但这种做法仍属资源浪费。采用数据注入模式时，本地数据至少可复用于交互操作及其他页面。

即便在交互性极低甚至无交互的页面中，这种方案仍会造成资源消耗。以Next.js文档为例，加载其主页时，页面大小约达750kB(其中HTML占250kB，脚本标签占500kB)，且内容重复出现两次。

您可在Mac上按Cmd + Opt + u(其他平台按Ctrl + u)验证此现象，随后使用Cmd/Ctrl + f查找博客内容(如“构建全栈Web应用”)，会发现该内容重复出现两次。由于这是React服务器组件的核心特性， 这种浪费无法避免 。

这种RSC格式确实存在更多冗余。但我实在不想深究为何字符串/_next/static/chunks/6192a3719cda7dcc.js会出现27次。搞什么鬼啊各位？你们带宽是白送的吗？？？

Turbopack 糟透了§

本节内容纯属吐槽。

• Turbopack 速度不快
• Turbopack 生成的代码在调试器中难以调试(开发模式下)
• Turbopack 在许多情况下抛出糟糕的错误信息

通常我不会为此单独开篇，但我想直接列举项目中的三个真实案例。

第一个案例发生在重构以满足服务器/客户端组件模型时，我误将一个客户端组件设为 async。这个错误特别恼人，因为它完全不指出问题所在，只包含了 服务器 的堆栈跟踪。

另一个糟糕的错误信息案例：

在修复第二个错误的根本问题后(具体原因已记不清)，开发服务器卡死，必须重启才能恢复。

最后一个问题是，我设置调试器断点时，变量名hello总被替换成__TURBOPACK__imported__module__$5b$project$5d2f$client$2f$src$2f$utils$2f$filename$2e$ts__$5b$app$2d$client$5d$__$28$ecmascript$29$__["hello"]之类的狗屁东西。

好吧。这简直糟透了。我们能怎么办？

在工作中无缝弃用 Next.js 和 Vercel§

Web 项目主要分为两类：

• 以静态内容为主的网站
• 包含大量动态交互组件的Web应用

而Next.js对这两类场景都适用性欠佳。若您属于第一类静态网站，建议选用Astro或Fresh。对于需要 React 完整功能的开发者，本节将分享我如何逐步无缝地用 TanStack Start 替代供应商锁定的 Next。

最初使用的是这个 Vite 配置文件。

vite.config.ts

const config = defineConfig(({ mode }) => {
    const env = loadEnv(mode, process.cwd(), "NEXT_PUBLIC_");
    return {
        // Use the Next.js default port 3000
        server: { port: 3000 },
        // Use the Next.js default env prefix "NEXT_PUBLIC_"
        define: Object.fromEntries(Object.entries(env).map(
            ([k, v]) => [`process.env.${k}`, JSON.stringify(v)])),
        plugins: [
            viteTsConfigPaths({ projects: ["./tsconfig.json"] }),
            tailwindcss(),
            // For ease of understanding from coworkers, I started porting
            // the routes in `src/tanstack-routes`. When the migration was
            // done, it would go back to the default `src/routes`.
            tanstackStart({
                router: { routesDirectory: "src/tanstack-routes" },
            }),
            viteReact(),
        ],
        resolve: {
            // The key to the incremental migration: redirect `next` elsewhere
            alias: { next: path.resolve("./src/tanstack-next/") },
            conditions: ["tanstack"],
            extensions: [
                // Allow a file named like `utils/session.tanstack.ts` to
                // override `utils/session.ts` when imported.
                ".tanstack.tsx", ".tanstack.ts",
                // Default import extensions
                ".mjs", ".js", ".mts", ".ts",
                ".jsx", ".tsx", ".json",
            ],
        },
    };
});

随后，我排查了所有Next.js API的使用场景，要么直接移除，要么为TanStack创建占位函数。例如src/tanstack-next/link.tsx实现了next/link：

src/tanstack-next/link.tsx

import { Link } from "@tanstack/react-router";
import type { LinkProps } from "next/link";

export default function LinkAdapter({ href, ...rest }: LinkProps) {
  return <Link {...rest} to={href as unknown as any} />;
}

部分占位实现极其简单。最初我对useRouter的实现仅为return {}，后来才逐步为该对象添加方法。由于是临时方案，代码无需追求整洁。

现在，新站点几乎可以导入所有客户端组件——要么通过模拟所需的 Next.js API，要么借助 .tanstack.ts 扩展按文件逐个重构逻辑。不久后，我便让网站首页在 TanStack Start 上正常运行，并合并了该分支。

首个PR仅支持单个页面，通过添加千行代码并删除40行代码实现。此前我已提交过移除少量next/image和next/font调用的补丁。

剩余工作是迁移所有其他路由。从Next.js迁移至其他框架时唯一损失的功能，是在UI中await数据获取函数的能力。实践中，将所有路由移入loader函数后，页面服务器端渲染时的行为变得清晰明了。对于需要多次数据获取的页面，可将这些请求合并为单次特殊API调用，一次性获取该页面的全部相关数据。

再次强调： 从服务器组件迁移的本质是简化代码——RSC天生会将你引向混乱的歧途 。网站几乎所有复杂模块都变得更易于工程师理解，唯一例外是团队需要适应新的文件系统路由规范。通过大量实例演示，我们最终都掌握了要领。

通过渐进式迁移，新代码不会破坏现有部署。TanStack逐步接管代码库，最终我们删除了所有Next.js占位符，获得了TanStack路由器提供的所有精美类型安全特性。最终网站在各维度都实现加速：开发模式响应更快、生产环境页面加载更迅捷、软导航更流畅，且成本低于Vercel托管的Next部署方案。

这种变化并非我们独有。尽管我尽量远离社交媒体，但有人发来了Brian Anglin在Superwall的工作成果，展示了TanStack Start实现的惊人CPU降幅。我还记得ChatGPT从Next.js迁移到Remix的讨论(随机网络闲谈： [1] [2] [3]) 约一年前。

next/metadata 非常出色§

在我看来，这是Next.js为数不多的优秀API之一，也是我们代码中迁移到TanStack后操作难度增加的唯一环节。为避免代码质量下降，我直接将他们的元数据API移植为常规函数，供所有人使用。最初我在NPM上实现了1:1移植，但今年初将其API简化为一个简洁易懂的文件。截至本文发布时，我已新增兼容 TanStack 的 meta.toTags API，可通过 JSR、NPM 安装，或直接复制到项目中使用。

注意 ：由于撰写本文的时间限制，该库尚未更新。我可能会在本周结束前(10月24日)或近期完成更新… 作为临时替代方案，我可将工作环境使用的版本分享至个人网站：meta.tanstack.ts。

// once in your project
import * as meta from "@clo/lib/meta.ts";

export const defineHead = meta.toTags.bind(null, {
    // site-wide options
    base: new URL("https://paperclover.net"),
    titleTemplate: (title) => [title, "paper clover"]
        .filter(Boolean).join(' | '),
    // ...
});

// for each page...
export const Route = createFileRoute("/blog")({
    head: () =>
        defineHead({
            title: "clover's blog", // templated with `titleTemplate`
            description: "a catgirl meows about her technology viewpoints",
            canonical: "/blog", // joined with `base`

            // When specified, configures Open Graph and Twitter embed,
            // using the page title and description as the default.
            // The defaults are good, but it supports more options.
            embed: {
                image: "/img/blog.webp",
            }, 

            // Every exotic meta tag is done with a JSX fragment. This
            // doesn't render React, it just loops through the tags.
            // My goal was to cover the most common 99% of uses.
            extra: <>
                <meta name="site-verification" content="waffles" />,
            </>,
        }),

    component: Page,
});

function Page() {
    ...
}

我的版本并未试图覆盖Next.js元数据对象的全部功能，而是通过内联JSX来弥补这一空白。

next/og同样值得推荐§

没有强硬立场。只是想提醒大家 @vercel/og 包的存在。

我的体验如常§

在 Next.js Conf 2024 大会上，所有人都在热议服务器组件。具体和谁聊过记不清了，但行业大佬们都对此充满热情。而我作为 RSC 打包端的实现者，早已洞察到这种模式的若干问题。随着 Next 15 去年“稳定化”应用路由器，众多公司开始基于它构建产品，亲身体验到这些陷阱。

我接触Next.js较晚，直到今年六月才开始使用15版。但活动期间交流过的每位开发者都认同我的观点。在Bun’s 1.3派对上讨论此议题时，所有参与者都赞同我的看法。甚至Vercel的员工也坦言不喜欢Next.js的实际使用体验。

我期待TanStack Start稳定后，能成为众人期待的Next.js替代方案。

选择尊重开发者的工具§

JavaScript 生态中的许多东西都一团糟。正是这种混乱让网页开发饱受嘲讽。我曾多次认为网页开发是无法收拾的烂摊子，但实际上混乱只存在于我常用的库中。剥离这些外壳后，现代网页开发技术其实非常出色。

自2024年末起，我便在完全抛弃框架的前提下从零构建这个网站，亲手编写了诸如TUI进度控件、 静态文件代理、增量构建系统等组件。这些开发过程带给我数年间最愉悦的编程体验。 paper clover 的访客获得了更优质的网站体验；我创建的微型库被提取为公共资源，实现多方共赢。

这种从零开始的开发模式对多数人而言过于苛刻，尤其在工作场景中。我认为至少应当将精力与资金投入那些尊重开发者的优质工具。而Next.js及其背后的公司Vercel，显然不属于此列。

若您使用Next.js时也感受到这种不被尊重的体验，请思考您与同事是否愿意继续支持他们的无服务器帝国。目前Vite生态系统似乎相当可靠，但我尚未积累其工具在生产环境大规模应用的经验。Void0推出的Vite+颇具潜力，但这些风险投资支持的工具能否长期尊重我们(终端用户与开发者)，唯有时间能给出答案。

截至本文撰写时，Next.js Conf 2025大会将于明日举行。与其购买800美元的门票，我决定将这笔钱捐给TanStack团队，以支持他们尊重并改善Web开发生态系统的行动。

未来展望

我正逐步用更优质的替代方案取代那些不尊重我的软件，例如GitHub、Visual Studio Code、DaVinci Resolve、Discord、Google Drive/Workspace等众多工具。我计划在此博客深入探讨技术实践(包括进展库开发、自建网站生成器的初衷、当前工作的经验总结)，并分享在Bun公司的过往项目(详述热重载技术、崩溃报告器及内置模块打包的复杂系统)。

本文文字及图片出自 One Year with Next.js App Router — Why We're Moving On

你也许感兴趣的：

• React 和 Next.js 中的关键漏洞：您需要了解的一切
• “完美”代码的致命错误
• 为何 Next.js 难堪软件工程重任？
• Next.js 真让人抓狂
• 在选择 Next.js 之前，您应该了解这些信息
• 【外评】不只是你，Next.js 也越来越难用了
• Qwik vs. Next.js：你的下一个 Web 项目应该选哪个框架？
• Next.js 越来越难用了
• Webpack落幕？其作者在Next.js 13中带来快700倍的替代品
• 译 | 为什么我会选择React+Next.js，而不是Vue或Angular？