Next.js is the most used React meta-framework in the world and one of the most resented. The numbers say both things at once. The State of JavaScri...
For further actions, you may consider blocking this person and/or reporting abuse
Your point about the training corpus and the pod-per-locale story are quietly making the same argument. That gravity only helps while you're on the rails. The moment you're in the case where the infra team is right but you're off them, like locale arriving as an env var instead of in the request, a model will happily generate the framework's native i18n path that assumes Next owns the locale, which is the exact wrong answer for that setup. So the corpus weight cuts the same way the opinionation does, it carries you when you honour the contract and quietly misleads you when you can't. Made me read "reliable bet" as really a bet that your requirements stay on the framework's happy path.
As a solo founder, I’m building BugDetectAI because I believe developers deserve a faster way to find and fix issues. Your feedback would mean a lot. Would you give it a try?****
I agree. That advantage only exists while you’re inside the same ecosystem. Once you step outside it, the benefit quickly fades. Code smarter with AI. Write code, fix bugs, and solve coding problems in just one click.
You've read it right, and I'd push it one step further. The corpus and the opinionation are the same force. The model writes good Next.js because it's trained on Next's patterns, so on the happy path, both carry you, and off it, both mislead you. It doesn't know the locale arrives as an env var, so it'll confidently generate the native path that assumes Next owns the locale. The common answer. The wrong one here. But that only bites if nobody catches it. Knowing the generated answer will rot in this setup is the actual job now, not a footnote. I wrote about that here: What AI Can't Compress.
One tweak, though: you read "reliable bet" as betting your requirements stay on the happy path. I'd say being forced off it isn't a risk you absorb; it's a signal. When infra's right and the contract can't hold, you don't keep paying the tax with wrappers and lint rules. You drop Next and pick something that fits. The bet's not a cage. You remake it the moment the fit breaks.
The trade-off between having the best developer experience and the most reliable ecosystem is something every team eventually faces. When you choose Next.js, you are essentially buying into a massive R&D budget and a community that solves edge-case problems before you even encounter them. I felt this exact tension when architecting our SaaS boilerplate, PubliFlow, where we had to decide between newer tools and the stable combination of Next.js, Supabase, and Tailwind. Ultimately, going with the reliable bet meant our users could focus on shipping features instead of fighting framework quirks. Do you think the upcoming React compiler changes will eventually make some of these heavier meta-frameworks feel less necessary, or is the routing abstraction here to stay?
I personally see Next as more than Front-end framework, and more as a fullstack solution, closer to a monolithic one that ironically. You can build API, create routes, and many more things that go behond a React implementation. On the other hand, I think with AI, frameworks will loose value in DX or composition, as less code will be written by hand, but by agents.
Viewing Next.js as a modern monolith makes perfect sense given how deeply it integrates routing and server logic. Your point about AI shifting the focus away from DX is fascinating, though. If agents handle the boilerplate, a framework's underlying architecture and deployment reliability might actually become the primary differentiators rather than the local coding experience. Do you think we will eventually see frameworks optimized purely for machine execution speed rather than human ergonomics?
The reliable bet framing makes total sense when you consider the ecosystem around Next.js. Even if another framework offers cleaner APIs, the sheer volume of integrations and community plugins means you spend less time debugging edge cases and more time shipping features. I've noticed this exact trade-off when putting together our SaaS boilerplate, PubliFlow, where choosing Next.js alongside Supabase and Tailwind gave us the most predictable path from prototype to production. Have you found that this reliability comes at the cost of vendor lock-in, or do the recent open-source shifts in the ecosystem balance that out for you?
I definitely think Vercel has the tendency to make it easier to use their products than anything else, and I would even say that some of their business behaviour isn’t always correct. Check out the story about what happened in December last year with a vulnerability they had inside their product  — CVE-2025-55182 exposed a critical remote code execution flaw in React Server Components that affected Next.js versions 15 and 16. But as I said in the post, it’s the most reliable bet, and as a product I think it’s still a very valid choice compared to others.
You're highlighting a crucial difference between framework reliability and vendor reliability. While Vercel's frictionless tooling keeps developers locked in, severe issues like the RSC remote code execution flaw you mentioned expose the danger of trusting a single company's opaque infrastructure. It makes me wonder if the community is quietly trading long-term security for short-term convenience by treating their ecosystem as the default.
As a solo founder, I’m building BugDetectAI because I believe developers deserve a faster way to find and fix issues. Your feedback would mean a lot. Would you give it a try?