Vercel has been a string of puzzling decisions since the introduction of the app router. Next could've become JS' Rails, instead it is a pile of confusing mess. Turbopack, caching, middleware (now called "proxy"), their layout components are silly, implementation of RSC, pushing for unfinished alpha versions of everything. Next is a conceptual mess of initialisms (RSC, SSR, PPR, SSG, ISG). Hosting integrations are semi-proprietary and they reliably break basic JS APIs like fetch and redirects.
And despite all of that, they don't ship the basics that every app needs, like i18n and auth.
Next should no longer be chosen under any circumstances.
there was a hey day where react was concerned with client side stuff only - yeah redux was a little complex but you needed to learn it once, react router didn't change every two days. we built incredible enterprise stuff around that stack react (with classes), react-router, redux. that's the last time I enjoyed react.
everything else is now a hamster wheel. running but staying in one place. marketing and money now drives everything else. Maybe there's a fire & motion strategy going on some of the places.
things like inertia help, but not by much.
You still can build websites this way. I was the first hire at my current company, I got to pick the stack of our frontend repo from the first commit. If you stay away from NextJS, things only improved since those heydays.
We're running tanstack-router, tanstack-query, and using vite underneath. That's about it. Each of these libraries are better and simpler than the standard redux/react-router/webpack from back in the day.
I've got lifelong backend developers reasonably (And somewhat happily) productive with the codebase.
This, with TypeScript strictness cranked all the way up. MUI for the component library, plus Playwright for integration-testing and hoverfly to stub/fake/mock the backend, and Open-API to define the APIs between app -> bff -> backend.
This stack, plus claude-code, with the whole project fully automated (i.e. claude-code run all the parts easily) - is a literal productivity super-power. You can crank out entire complicated LoB apps, 10 - 30 pages of distinct, medium-complicated functionality in about a week, if not less - instead of weeks or months. Fully tested, production-ready codebase, not prototype-tier/vibe-code.
Next.js isn't React. Plain React has been pretty stable, if you ignore server components. And it's quite easy to ignore them despite all the noise around them, they're entirely optional.
PPR is a fun read. It's like reading the reinvention of the wheel 15+ years after the first Ferrari came out.
I can't imagine how slinging ungodly obfuscated JS blobs^w chunks over the wire can ever be the next Rails...
This is beside the point. And I can't imagine how anyone would want to write templates in anything other than JSX and yet here we are.
Rails and friends aren't about a single technical choice, but providing a complete and opinionated framework to build web apps that conceptually fit in to one person's head.
Rails is that. Django is that. Laravel is that. Next is the opposite, where Next-specifica around caching won't fit in to a single head, let alone the app you're building.
How can anything that is completely un-debuggable (like the mentioned chunks) fit in any one person's head?
Good luck with that.
We chose Next.js, exactly because they are the only option in many enterprise products as the extension SDK.
No one wants to land into a project and sell the customer that they want to use DYI framework instead of the SDK of the product they are paying for.
Then you didn't choose, you are forced to.
For the vast majority of cases there are many non-DIY alternatives within the React world and that is before asking the "do we even need React?" which if course one should.
If I get to chose then most likely it won't have any JavaScript at all, or plain vanilajs.
Fair but that sounds like a requirement of your project.
Which is completely ignored in an assertion like,
> Next should no longer be chosen under any circumstances.