Awesome! Too bad Next.js will never profit from these incredible community efforts, because Vercel suffers from NIH.
Next started with Turbopack alpha as a Webpack alternative in Next 13 (October 2022) and finally marked Turbopack as stable and default in Next 16 (October 2025). They also ran sketchy benchmarks against Vite back in 2022 [0].
Next's caching has a terrible history [1], it is demonstrably slow [2] (HN discussion [3]), RSCs had glaring security holes [4], the app router continues to confuse and relied on preview tech for years, and hosting Next outside of Vercel requires a special adapter [5].
Choosing Next.js is a liability.
0 - https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...
1 - https://nextjs.org/blog/our-journey-with-caching
2 - https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...
3 - https://news.ycombinator.com/item?id=43277148
There are several much better options right now. My favourite is Tanstack Start. No magice, great DX
I recently migrated to Tanstack for this and confirm it's been strictly better so far, especially having dynamic paths in my use-case (makes a hybrid app much more realistic)
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.
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).
And to sell Vercel on top.
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?
See Sitecore Cloud, Sanity, Contentful,....
I checked sitecore cloud to have special integration for nextjs and reactjs. But it also support vanilla js as well.
Are there really anyone who is exclusive to nextjs?
In many places they will say it is supported, but when you look into the details only React/Next.js work out of the box without additional work.
A bit like you can deploy Next.js on Vercel, or do it yourself somewhere else.
(haven't tried it myself)