And such an extrodinary different is usually holding the tool wrong, but Next has years old open issues for many of the causes here (like forced output tracing) and has just ignored them. Possibly because the Next team's preferred deployment environment isn't affected?
5 or so years ago, Next was a pretty solid option to quickly build up a non SPA, when combined with the static export function. It wasn't ideal, but it worked and came batteries included. Over time it's become more bloated, more complicated, and focused on features that benefit from Vercel's hosting – and static builds can't take advantage of them.
These newer features seem of limited benefit, to me, for even SPAs. Why is there still not a first class way of referencing API routes in the client code that provides typing? Once you reach even medium scale, it becomes a mess of inteprolated string paths and manually added shared response types.
The React team (really Vercel + Shopify) decided to use the supremely misleading names "Server Component" and "Client Component" for two things that do not affect CSR vs SSR.
Even if you label the root of your app "use client" (thus opting out of all the new complexity around RSC and server actions), it's still getting rendered server side.
There is a decent bit of history around that page and whether some things should go in a collapsible div and whether that was prioritizing certain frameworks over other ones.
One thing I'm still salty about is that CRA isn't mentioned anywhere (in the entire site). It's like it never existed.
The general TLDR is:
- CRA was listed in the _old_ docs site
- The new docs site coincided with the React team emphasizing "frameworks" to provide an all-in-one build experience and hopefully lead to better apps.
- That also meant no ala-carte build tools were listed. This made many people (including me) unhappy.
- CRA broke when React 19 came out in Dec 2024. This caused problems for beginners.
- I pushed the React team to both deprecate CRA and finally rewrite the setup pages to list other build tools as valid options.
I wrote up a much longer background of what happened around the "frameworks" push and this docs page here:
- https://blog.isquaredsoftware.com/2025/06/react-community-20...
And here's the issue I filed pushing the React team to deprecate CRA (after some online discussion):
- https://github.com/facebook/create-react-app/issues/17004
and a follow-up PR where I tried to rewrite the initial rather confusing post-CRA-deprecation "Creating Your Own Framework" page with a more relevant "Creating a React App" page:
- https://github.com/reactjs/react.dev/pull/7618
but the overall point of _all_ of this is that CRA was unmaintained as of 2023, the community had _already_ moved on to Vite, and all this was an attempt to get the React docs to reflect that reality.
I've been following you and some of the other main React devs.
> That also meant no ala-carte build tools were listed. This made many people (including me) unhappy.
I had followed a decent bit of this back on Twitter, and appreciate you guys trying to make the documentation better (despite all of the drama that came up as a result).
And while it's definitely slowed down a bit, I still randomly see a "What happened to CRA" on the r/react sub.
I guess what bothers me the most is that CRA was not only mine, but quite a few others first introduction to React. And it's just weird that it wasn't even called out in the new docs (even back in 2022-2023). Like it had never existed.
Regardless, I appreciate that you guys care enough to help move React in the right direction. A lot happened while this was going on, and you guys put up with A LOT during this process.
As a side note, I'm slowly moving out of Next.js, as you said, is bloated, full of stuff that is just noise and that benefits them (more network requests more money) for little user benefit.
Right now for me the gold standard is Vite + Tanstack Router. (And Elysia for api/server, but thats unrelated).
JSX is a nice server side templating language. There a lot of people who aren't dependency conscious, and a lot of people who love react, and there is quite a bit of overlap in those two groups. I've used bun + preact_render_to_string for server side JSX templates before and it was nice. When I did it seemed that bun somewhat embraced react, and I could imagine react being the path of least resistance to server-side JSX there for some of the folks in the aforementioned groups.
Fetch index.html -> Fetch JS bundle -> Evaluate -> Fetch /users/me
You do:
Fetch index.html (your page is rendered at this point) -> rehydrate with client side JS for interactivity in the background
It's a pretty smart solution I think, and many people are still sleeping on the whole SSR topic.
Getting SSR right is tricky and barely even matters for a lot of use cases I’m seeing with Next.
Better server/client integration when it comes to rendering UIs is neat, but there are other technologies that solve for that at a more fundamental level (htmx, phoenix)
It is broadly useful and relatively easy to use while still staying within the React framework the developer knows well.
That said, I didn't build more than a demo app with NextJS, so I don't know a lot about possible issues. Just the concept seems to be good.
Imagine a page that loads html during the first load, and then performs client-side routing during subsequent navigations. Is it an SPA? Is it not an SPA?
And to sell Vercel on top.