You don’t need Next.js

You don’t need Next.js

We moved the ComfyDeploy dashboard from Next.js to just React

• The construction period from 3 min on 18 sec
• Hot reload below 200ms
• Everyone on the team is happier (like, happier)

My tweet about it blew up, so I thought it would be helpful to break down exactly why we took this step.

I started ComfyDeploy as an open source project (GitHub) – a full stack app with Next.js doing all the heavy lifting for frontend and backend. We have Drizzle + Server Actions that make everything type-safe and smooth.

All was well until the fan stuff started:

• We received an unexpected $2,000 bill from Vercel due to high API usage from a user
• Testing APIs becomes a nightmare, because we have a lot of server actions mixed in with api routes.
• Construction times have been so slow it’s like watching paint dry.
• Local dev is brutal – every little change causes a full SSR reload

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 main reasons: First, as an API platform, we had to scale the functional limitations of Vercel – a dedicated server to automatically scale more factor than the Next.js API layers. Second, since our dashboard is primarily React-based and does not require Next.js’s server-side features, the framework’s optimizations add unnecessary overhead. Moving to a pure React setup was the logical choice for our use case.

As we continue to grow, we continue to add more libraries. Construction continues slowly and slowly. At one point, after adding Sentry, it hit 7 minutes. seven. Minutes. Fixing a typo literally gives you a coffee break.

The local dev situation isn’t much better. We run this monorepo on Turborepo, not to mention it becomes a pain to manage. Starting the dev servers feels like booting up an old Windows 95 PC, on my M3 Max Macbook Pro.

Then Next.js 15 RC dropped. I thought, “Hey, Turbopack might save us!” Spent a week upgrading, only to run into compatibility issues. A week later, we’re back at 14, wondering why we’re spending more time fighting Next.js than actually building our product.

One morning, I was sitting there looking at Next.js 10 seconds just to start. That was it. I am enough.

“Hey team, let’s get back to React. Give me a week.”

We all install TanStack Router + Rspack. Moved our entire shadcn folder, our components, everything. And you know what? Within a few days, we seemed to be breaking chains we didn’t know we had:

• Instant dev server – under 2 sec.
• Built in Vercel underneath 18 sec.
• Really web dev fun again!

The migration forced us to clean house as well – removing old features we didn’t need, removing unused dependencies, and completely rethinking our API setup. Sometimes you have to tear things down to build them back up better.

Next js 15 with turbo mode

Here is our local dev experience with next js 15 with turbo mode

React Tanstack Router + Rspack

Let’s be honest – every technical decision has trade-offs. Here’s what we left and gained:

What Are We Missing?

1. Co-location of Frontend and Backend

Now we have separate frontend and backend codebases but with better separation of concerns, clearer boundaries

2. Next.js Caching Features

Missing built-in caching mechanisms but in reality most of our data needs updates in real time. We ended up implementing specific caching where absolutely necessary

1. Pre-rendering and Initial Load

No more automatic static generation. More conscious code splitting is required to preserve page loading speed. But actually improved the UX. No more “ghost clicks” where users see buttons they can’t interact with because the JS hasn’t loaded yet. More predictable load states

4. Server components and actions

The “magic” of the server components is gone. Server Actions make quick data retrieval easy ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​frontier​​​​​​​ needs – poll updates are harder to server actions are blocked.

The Reality Check

Here’s the thing: these “losses” force us to make better architectural decisions. Instead of relying on framework magic, we need to:

• Design our API contracts more thoughtfully
• Implement caching where it matters
• Consider data flow and state management more deliberately

Sometimes constraints are exactly what you need to build something better.

If you want to compare the two versions ComfyDeploy React vs 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 great (Server Actions – just REST API calls).

But for most products? It’s like using a sledgehammer to hang a picture frame. The jump from Next.js 14 to 15 really drives this home – dependencies are breaking left and right, and even in Turbo mode, the dev server is slow enough to make you want to bang your head against wall.

We still keep Next.js for our landing page and SEO stuff, but the dashboard? Pure React on TanStack Router + Rspack. Our API? A simple Python FastAPI server that cools Google Cloud Run, scaling as needed.

Sometimes less really is more. And in our case, smaller Next.js means more shipping, faster, and happier developers.

And I want to be clear – Vercel itself is an amazing company that builds incredible products. We still use and love their platform for various projects. Next.js turned out to be more than we needed for our specific use case at this stage of our product.

We’re looking for people who are passionate about dev delivery tools, from pushing frontend pixels to optimizing backend deployment models. DM me twitter if you are there.