You don't need Next.js – Why we migrated from Next to React
In this technical retrospective (2025), @bennykokmusic shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Post-ZIRP & AI (2023–2026)
COMMUNITY SCORE ★ 105 points
TOTAL DISCUSSIONS 99 comments
I've built my latest project[1] with Next.js and it's often felt pretty hectic to use.
App vs. pages router, accessing cookies requiring different APIs between the client-side and the server side, env vars being accessed via `process.env.NEXT_PUBLIC_*` which gets rewritten into literal value of the env var (so if you access `process.env` directly you're very confused).
I guess I was hoping that I'd be able to write code which would work on either the client-side or the server-side with minimal changes. But that's not what I experienced. For what Next.js does provide, it doesn't feel worth the overhead and the learning required to do it "the Next.js way".
1 - https://onlyhumanhub.com
“We received an unexpected $2,000 bill from Vercel due to high API usage from a single user”
Skill issue.
Testing APIs became a nightmare, because we had a lof of server actions mixed with api routes.
Sounds like you designed the app poorly.
Build times got so slow it felt like watching paint dry.
Heard but is there any situation where you’d a sub 3 minute deploy.
Local dev was brutal - every tiny change triggered a full SSR reload.
I have never noticed this as an issue across any Next app of any size that I’ve worked on.
I agree that next probably doesn’t scale but it’s pretty good for 0-to-1 without having to worry about setting up routing, tailwind, basic API etc
This is so true! Our codebase got radically simpler when we did the exact same thing. And faster too, in terms of page rendering. It is very unfortunate that the whole community is being pushed onto frameworks like this unnecessarily.
All most folks need is `npx rsbuild init`:
https://rsbuild.dev/
(And I love that the post authors are using rspack! I read the post after posting this comment. This was our exact same process. No more overhead of next -- just used rspack/rsbuilld and a simple router and beautiful simplicity everywhere, including 10ms hot reloads)
The Next.js team keeps hiding the usefulness of React Server Component for the ease of development and Vercel deployment. It's a gatekeeper at its best.
Why not exposing an API for RSC so that i can imperatively fetch a RSC page with normal fetch call ? Why hiding such a killer feature so that you don't need HTMX anymore.
Also, why conventionally forcing the "RSC page" can't access the Request object in lue of caching. Instead of flexibility of a framework, you force things which users don't prioritize.
Ah, one last point, file system routing without anyway to opt-out is a red flag of the architecture as well.
We’re also seeing super slow dev build times with Next.js. It takes around 12 seconds for the initial page and then 2-3 seconds for other pages.
I always thought it was an inherent issue in this app due to the many dependencies (9000+ modules for each page) but I’m going to try what the article suggests.
Does Rsbuild or any other build tool provide an alternative to Static Site Generation with automatic code chunking? Because this part of Next.js is great. The production app is super fast to load.
Edit: looks like Rspress does exactly that.