You don't need Next.js
你不需要 Next.js

We migrated the ComfyDeploy dashboard from Next.js to just React
我們將 ComfyDeploy 控制台從 Next.js 遷移到僅使用 React

TL;DR  長話短說

• Build time went from 3 mins to 18 secs
  建置時間從 3 分鐘縮短到 18 秒
• Hot reload under 200ms  熱重新載入時間低於 200 毫秒
• Everybody on the team is happier (like, way happier)
  每個團隊成員都更快樂了（非常快樂）

My tweet about this blew up, so I thought it'd be helpful to break down exactly why we made this move.
我關於此事的推文爆紅，所以我認為詳細說明我們做出此舉的原因會很有幫助。

How we got here
事情的來龍去脈

I started ComfyDeploy as an open source project (GitHub) - a full stack app with Next.js doing all the heavy lifting for both frontend and backend. We had Drizzle + Server Actions making everything type-safe and neat.
我將 ComfyDeploy 作為一個開源專案啟動（GitHub）——一個全棧應用程式，使用 Next.js 負責前端和後端的所有繁重工作。我們使用 Drizzle + Server Actions 使一切類型安全且整潔。

It was all good until things started hitting the fan:
一切都很順利，直到事情開始一團糟：

• We received an unexpected $2,000 bill from Vercel due to high API usage from a single user
  我們收到 Vercel 開出的 2,000 美元意外帳單，原因是單一用戶的高 API 使用量。
• Testing APIs became a nightmare, because we had a lof of server actions mixed with api routes.
  API 測試變成一場噩夢，因為我們混雜了大量的伺服器動作和 API 路由。
• Build times got so slow it felt like watching paint dry.
  編譯時間變得非常緩慢，感覺像是在看油漆乾燥一樣。
• Local dev was brutal - every tiny change triggered a full SSR reload
  本地開發環境糟透了——每一次微小的改動都會觸發完整的 SSR 重新載入。

Next.js is a powerful full-stack framework, but its all-in-one approach can lead to development complexity as your application grows. Our decision to migrate was driven by two key factors: First, as an API platform, we needed to scale beyond Vercel's function limitations - a dedicated auto-scaling server made more sense than Next.js's API layers. Second, since our dashboard was primarily React-based and didn't require Next.js's server-side features, the framework's optimizations were adding unnecessary overhead. Moving to a pure React setup was the logical choice for our use case.
Next.js 是一個強大的全端框架，但隨著應用程式規模的增長，其一體化的方法可能會導致開發複雜性。我們決定遷移是由兩個關鍵因素驅動的：首先，作為一個 API 平台，我們需要超越 Vercel 函數的限制——專用的自動擴展伺服器比 Next.js 的 API 層更合理。其次，由於我們的儀表板主要基於 React，並且不需要 Next.js 的伺服器端功能，因此該框架的優化增加了不必要的開銷。對於我們的用例來說，轉向純 React 架構是合乎邏輯的選擇。

The build up  事情的發展

As we kept growing, we kept adding more libraries. The build just kept getting slower and slower. At one point, after adding Sentry, it hit 7 minutes. Seven. Minutes. Fixing a typo literally give you a coffee break.
隨著我們的持續成長，我們不斷添加更多函式庫。編譯速度越來越慢。有一次，在添加 Sentry 後，它竟然花了 7 分鐘。七分鐘！修正一個錯字竟然能讓你悠閒地喝杯咖啡。

The local dev situation wasn't any better. We're running this monorepo with Turborepo, not to mention it became such a pain to manage. Starting up dev servers felt like booting up an old Windows 95 PC, on my M3 Max Macbook Pro.
本地開發環境也沒有好到哪裡去。我們使用 Turborepo 運行這個單體倉庫，更不用說管理它變得非常痛苦。啟動開發伺服器就像在我的 M3 Max Macbook Pro 上啟動一台舊的 Windows 95 電腦一樣。

Then Next.js 15 RC dropped. I thought, "Hey, Turbopack might save us!" Spent a week upgrading, only to run into compatibility issues. Another week later, we're back on 14, wondering why we're spending more time wrestling with Next.js than actually building our product.
然後 Next.js 15 RC 推出了。我心想：「嘿，Turbopack 可能能拯救我們！」花了一週時間升級，卻遇到了相容性問題。又過了一週，我們又回到了 14 版，想知道為什麼我們花在與 Next.js 搏鬥上的時間比實際構建產品的時間還多。

The turning point  轉捩點

One morning, I'm sitting there watching Next.js take 10 seconds just to start up. That was it. I'd had enough.
有一天早上，我坐在那裡看著 Next.js 花了 10 秒鐘才啟動。就這樣，我受夠了。

"Hey team, we're going back to React. Give me a week."
「嘿，團隊，我們要回歸 React 了。給我一週時間。」

We went all in with TanStack Router + Rspack. Moved our entire shadcn folder, our components, everything. And you know what? Within days, it felt like we'd broken free from chains we didn't even know we had:
我們全力投入 TanStack Router + Rspack。遷移了我們的整個 shadcn 資料夾、我們的組件，所有一切。你知道嗎？幾天之內，感覺我們擺脫了我們甚至都不知道存在的枷鎖：

• Instant dev server - less than 2 secs.
  即時開發伺服器——不到 2 秒。
• Vercel build under 18 secs.
  Vercel 編譯時間少於 18 秒。
• Web dev actually fun again!
  網頁開發再次變得有趣！

The migration forced us to clean house too - ditching old features we didn't need, dropping unused dependencies, and completely rethinking our API setup. Sometimes you need to tear things down to build them back better.
這次遷移也迫使我們進行了徹底的清理——放棄了不需要的舊功能，刪除未使用的依賴項，並徹底重新思考我們的 API 架構。有時你需要拆毀才能更好地重建。

The Numbers  數據

Next js 15 with turbo mode
Next js 15 搭配 turbo 模式

Here's our local dev experience with next js 15 with turbo mode
以下是我們使用 Next js 15 搭配 turbo 模式的本地開發體驗

React with Tanstack Router + Rspack
使用 Tanstack Router + Rspack 的 React 應用程式

The Trade-offs  取捨

Let's be real - every technical decision comes with trade-offs. Here's what we gave up and gained:
讓我們誠實面對—每個技術決策都有其權衡取捨。以下是我們放棄和獲得的：

What We Lost  我們失去的

1. Co-location of Frontend and Backend
   前端和後端程式碼共置

Now we have separate frontend and backend codebases but end up having better separation of concerns, clearer boundaries
現在我們擁有分開的前端和後端程式碼庫，但最終獲得了更好的關注點分離和更清晰的界限

2. Next.js Caching Features  Next.js 快取功能

We lost built-in caching mechanisms but actually most of our data needed real-time updates. We ended up implementing specific caching where actually needed
我們失去了內建的快取機制，但實際上我們的大部分數據都需要即時更新。我們最終在真正需要的地方實作了特定的快取

1. Pre-rendering and Initial Load
   預渲染和初始載入

No more automatic static generation. Required more thoughtful code splitting to save page load speed. But actually improved UX. No more "ghost clicks" where users see buttons they can't interact with because JS hasn't loaded. More predictable loading states
不再有自動靜態生成。需要更周全的程式碼分割以節省頁面載入速度。但實際上改進了使用者體驗。不再有使用者看到無法互動的按鈕（因為 JS 尚未載入）的「幽靈點擊」現象。更可預測的載入狀態

4. Server Components and Actions
   伺服器元件和動作

Lost the "magic" of server components. Server Actions made quick data fetching too easy (maybe too easy?) Forced us to design better, more intentional APIs Better for our real-time needs - polling updates were actually harder with blocking server actions.
失去了伺服器元件的「魔法」。伺服器動作讓快速數據擷取變得過於容易（也許太容易了？）。迫使我們設計出更好、更有目的性的 API。更符合我們的即時需求—使用阻塞式伺服器動作實際上更難進行輪詢更新。

The Reality Check  現實檢驗

Here's the thing: these "losses" forced us to make better architectural decisions. Instead of relying on framework magic, we had to:
事情是這樣的：這些「損失」迫使我們做出更好的架構決策。我們沒有依賴框架的「魔法」，而是必須：

• Design our API contracts more thoughtfully
  更用心設計我們的 API 協定
• Implement caching where it actually mattered
  在真正需要的地方實作快取機制
• Think about data flow and state management more deliberately
  更謹慎地思考數據流和狀態管理

Sometimes constraints are exactly what you need to build something better.
有時候，限制正是打造更優良產品的關鍵。

Conclusion  結論

If you want to compare the two version ComfyDeploy React vs ComfyDeploy Next.js.
如果你想比較 ComfyDeploy React 和 ComfyDeploy Next.js 這兩個版本。

Next.js is great for what it's meant to do - landing pages, SEO stuff, that kind of thing. It makes simple concepts look fancy (Server Actions - is just REST API calls).
Next.js 非常適合其設計目的——落地頁面、SEO 優化等等。它讓簡單的概念看起來很炫（伺服器動作——只不過是 REST API 呼叫）。

But for most products? It's like using a sledgehammer to hang a picture frame. The jump from Next.js 14 to 15 really drove this home - dependencies breaking left and right, and even with Turbo mode, dev server is still slow enough to make you want to bang your head against the wall.
但對於大多數產品來說？這就像用大槌子掛相框一樣。從 Next.js 14 升級到 15 真切地體現了這一點——依賴項不斷崩潰，即使使用 Turbo 模式，開發伺服器仍然慢到讓人想撞牆。

We still keep Next.js around for our landing page and SEO stuff, but the dashboard? Pure React with TanStack Router + Rspack. Our API? A simple Python FastAPI server chilling on Google Cloud Run, scaling whenever it needs to.
我們仍然保留 Next.js 用於我們的落地頁面和 SEO 優化，但儀表板呢？純 React 搭配 TanStack Router + Rspack。我們的 API？一個簡單的 Python FastAPI 伺服器輕鬆運行在 Google Cloud Run 上，按需擴展。

Sometimes less really is more. And in our case, less Next.js meant more shipping, more speed, and more happy developers.
有時候，少即是多。在我們的案例中，減少 Next.js 的使用意味著更快的發佈速度、更高的效率以及更快樂的開發者。

And I want to be clear - Vercel itself is an amazing company that's built incredible products. We still use and love their platform for various projects. Next.js just turned out to be more than what we needed for our specific use case at this stage of our product.
我想明確一點——Vercel 本身是一家很棒的公司，打造了令人驚嘆的產品。我們仍然在各種項目中使用並喜愛他們的平台。只是 Next.js 對我們目前的產品來說，功能過於強大。

Lastly!  最後！

We are looking for people obsessed with shipping dev tools, from pushing the pixels on the frontend to optimizing diffusion models in the backend. DM me on twitter if you're down.
我們正在尋找熱衷於開發開發者工具的人才，從前端像素的調整到後端擴散模型的優化，應有盡有。如果你感興趣，歡迎在 Twitter 上私訊我。