You don't need Next.js – Why we migrated from Next to React
comfydeploy.com
comfydeploy.com
The biggest problem with React is the JS bloat that's sent to the browser. Though as long as you do server side rendering and don't even ship the JS to the FE, Next.js is a pretty good static site generator.
Yes, yes, I you want to make a plain HTML form its fast enough, but for a startup 99% of customers want to feel assured by it having a look and feel which simply takes too much time if you are building things up without a framework
There's a web app I use (ClickUp) where I have to watch UI elements load one-by-one, like I'm back on dial-up or something. I'm convinced they end up with more CPU load just doing all the TLS handshakes than they would if they just sent me all the HTML in one go.
OK well I've done both and I have to say no it's not, but probably my definition of simple is simpler than yours. It also seems to me that the original comment used a simpler than yours model of simplicity.
>Next.js is a pretty good static site generator.
my experience is that Next.js is a lousy static site generator, but reasonable if you want to use React.
Simple is better, but bare doesn't necessarily mean simpler.
Isn't this rather circular? It's only this way if you already know React well enough to be fluent. Learning React and all it's conceptual baggage is a huge jump from understanding html/css/basic js plus the HTTP request/response cycle (all things which you'll need to understand even if you do use React)
Honestly - this sounds a little like Stockholm Syndrome. I've spent a long time actively avoiding React and nothing I've read or seen has led me to think that was a poor decision. Quite the opposite - I feel progressively more vindicated with every passing year.
> The biggest problem with React is the JS bloat that's sent to the browser
What does React bring then? It is slow, overengineered and bloated. It is also the only thing many developers know. Just like PHP 20 years ago.
Throw your container on a VM, make systemd or even runit keep it running. It scales fine to half dozen boxes if needed. Same for your Postgres DB. For extra fancy points, keep a hot standby / read replica, and pick up any of the manual switch-over scripts.
Should keep you running until dozen million DAU, with half-day spent on the initial setup.
You build an artifact in CI, you spend a few minutes writing your deployment yaml, and then you deploy it. There's no more work after that.
What is so freaking hard about kubernetes? Why is everyone losing their minds over it? It isn't rocket science and it doesn't take a lot of time.
The nightmare is maintaining flaky snowflake bare metal machines.
It’s a lot of up front knowledge needed for marginal benefit at small to mid scales.
There’s a lot of steps if the “write your deployment yaml” step.
If you need some things like load balancing and zero downtime deploys etc you probably will build your own k8s which is often worse
Kubernetes is not the only game in town.
Sometimes shipping asap is more important. As with just about anything in tech, it’s about tradeoffs.
I may be biased, since I worked in devops before k8s came out, but building a decently scalable system architecture with load balancing and rolling deployments is pretty straightforward with monolithic systems. Especially since service discovery isn’t really a concern. Horizontal scaling works well in many many cases.
Realistically any app simple enough to be deployed by hand with a few docker containers will not be difficult to convert to k8s anyway.
Kubernetes out of the box is not ready to go. What Ingress are you going to use? Ingress-Nginx. Cool cool, How is that getting deployed? Helm Chart. How do we keep track of that being kept up to date and who deployed it? ArgoCD. So who is going to teach all CRDs for Argo and how they work with each other? SREs. You understand we dislike the devs and last thing we want to do is hold classes they don't want to learn? JUST BUILD A PLATFORM. And here we go.
So out of box, most people deploy Kubernetes + 8 "plugins" and it's Frankenstein monster that's you have to manage or it will decide to kill all the workloads one day.
EDIT: I'm didn't even discuss certificates for that ingress or all monitoring/logging this cluster will need to make sure it's properly operating.
Also, managing a CI pipeline isn't something very easy to start with, there are entire teams in companies that only do that.
In contrast running a simple server is much more simple, you install a Linux OS (probably Ubuntu server, or Debian), install a web stack (for example Apache, PHP, Mysql or Postgres these days), copy the files of your website in the root directory (/var/www), or if you are fancy pull a git repository on the server so you can update it with a simple "git pull", if you need more websites on the same machine configure virtualhosts (or use one of the many software that have a GUI to configure virtualhosts).
The second solution is much more simple, in fact is the most used solution as far as I see. Most websites doesn't need high availability, if the website of the bike repair shop that I have 100 meters down the street goes offline for a couple of minutes or even one day because I'm doing maintenance on the server really nobody notices it.
> In your opinion, because they’re stupid?
If they are doing that to keep nginx running, that might be the case or they are super clever to do that for a higher salary at the cost of their employer.
Students are the one case in which I'd say this is good.
The vast majority of the stuff students do is not going to be successful. The purpose here is not to build stuff, it's to learn how to build stuff, and in that case exploring technologies is a net win.
A couple of years ago, somebody tweeted something along the lines of "did you know you can POST an html form without using javascript?". The replies were incredible, because they revealed how many folks could write a full blown React app to post a form, but didn't know how to do it with just <form>.
I agree: it's terrible that kids would go straight to React without trying plain html + js first, but they do this because they often don't know any other way of doing it.
The other thing is apps mostly work now. Even 10 years ago people (including devs) would tolerate a flaky application. Now days everyone expects five-nine uptime and zero data loss and seamless cross platform functionality.
If you start off with some "toy" version you fool yourself into thing this idea is not as hard as it sounds. Then once you hit the wall of production reality you start to realize just how hard something is going to be in production and that's why the market is still open for your idea. Its why there are so many profiles on github with tens or hundreds of abandoned projects.
There's probably a lot of greybeards out there that will say all you need on a computer is a terminal and emacs. They might be right but you cannot scale/sell it and everything in-between is just a compromise.
Maybe the students want to learn a popular framework in order to have job? That is exactly the reason I learned Nextjs and lo and behold, it proved to be useful for me and my employer..
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".
Use pages and remember that env var patten and you're good.
I still use the pages system and actually find myself increasingly moving back to just using Vite + React if I don't need access to the node-based API.
All most folks need is `npx rsbuild init`:
(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)
It's like having all the simple power of a PHP app except with a nice type system and the ability to seamlessly include interactive, stateful client components at the "leaf level" of my view tree.
if it's not a state management library, it's a meta framework, if it's not a metaframework, it's a data fetching library. so many choices to do one simple thing put data coming from the server on a page.
then why do people need it to make complicated as if you're hatching dragon eggs with alchemy ?
Additionally typescript needs a compile step anyways so it's not super complicated to just add react to it.
I think many people bounced off React 5 years ago when in 2025 React apps are easy to get started with (basically no config), have negligible hot reload + build times, and largely have become a joy to use.
I (and the post and many comments here) think many people are bouncing off React now, because of NextJS and Vercel.
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.
If filesystem routing isn't something you enjoy, Next.js probably isn't the right tool for you.
> Layouts do not rerender. They can be cached and reused to avoid unnecessary computation when navigating between pages. By restricting layouts from accessing the raw request, Next.js can prevent the execution of potentially slow or expensive user code within the layout, which could negatively impact performance.
I don't like this limiting "I know best what's good for you" attitude in my tooling.
Yes limits are desirable to avoid footguns but this seems like too dumbed down of a restriction for little gain.
Docs: https://nextjs.org/docs/app/building-your-application/routin...
But page load optimization does typically bring better user engagement so it’s not just an SEO strategy.
as an end user, the only downside would be the typical SPA ones, such as the client needs to render the site with JS like you mentioned (except in cases where we use pre-rendering).
here's an example site built with Routerino if you'd like to experience what it is like in usage: https://virtourlimited.netlify.app/
Why use a framework at all?
Typically dashboards will be accessed on a desktop in an office setting with good internet, so initial load and asset size isn't a huge issue. Then you get benefits like client side routing which feels snappy, and live updating widgets is pretty simple. Of course it's a matter of opinion though.
I think what you mean is that elements shared across pages (the header, the navigation bar etc) do not have to be sent again.
But those are very small anyhow. And you could bring the size down to zero by making them web components. Web components are cached along with the JS that defines them.
Things get worse when you bring Javascript into the mix. You need to create Javascript code with your template engine without any Javascript toolchain.
Hard no to the string concat approach for me.
What do you mean by "no mapping to Javascript"? It is not as if React is part of the Browser API.
Discussion at the time: https://news.ycombinator.com/item?id=38018217
Hopefully, turbopack and RSC fixes some of these issues in future.
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
Though I can sympathise with wanting the simplicity of React, after all it's just a diffing algorithm and markup.
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.
I can improve the user experience faster and more reliably if i can iterate faster.
While I wouldn’t agree with the sibling comment that says it needs to be measured in milliseconds, I will say that the faster it is, the more motivated I am to work on it as well.
I'm curious how you define your routes cause I've got several big apps with lot of routes, nested routes and complex access permissions for each route and it never entered in my mind that there was anything complicated about it.
Why it's important for you? How many times in a day do you need to build the app?