Next.js solved a problem, then added new ones

React alone meant hand-rolling server-side rendering — a custom server.ts and ReactDOMServer wired up by hand. Next.js was built to remove that pain, not create it. The trade is a framework with enough surface area that one wrong move in the wrong layer is a security bug, not just a bad request.

Before Next.js, server-rendering a React app meant building the plumbing yourself — a server.ts wired to ReactDOMServer, routing and code-splitting done by hand, data fetching stitched together per page. It worked, but every team rebuilt the same infrastructure slightly differently, and slightly wrong.

Next.js wasn't someone deciding to make that complicated — it was the opposite: a framework built specifically to remove that pain, with SSR, routing and code-splitting as defaults instead of a bespoke setup. What it's picked up since is a different kind of complexity: a routing model, a server/client boundary, and a middleware layer with enough surface area that getting one of them wrong isn't just a bug, it's a security issue.

Where the wrong move actually bites

• A value that should stay server-only ends up in a client component and ships in the bundle.
• Authorisation logic placed in middleware rather than next to the data it's supposed to protect — assumed to run, in cases where it doesn't.
• Server Actions and route handlers treated as private just because there's no visible link to them.

The framework didn't add unlimited problems — it added a bigger surface, and a bigger surface punishes an unread convention harder than plain React ever did.