Next.js

Next.js is worth choosing for one reason above the rest: it makes the default answer server-rendered HTML, and it makes shipping JavaScript an explicit decision rather than an accident. Everything else about it follows from that.

The decision that matters on any real project is where each piece of work lives. Data access and business rules belong on the server, where they cannot be inspected or bypassed from a console and where a second client cannot drift from the first. Interactivity is marked as client code and kept to small islands, because a component marked client for the sake of one useState turns every module it imports into shipped bytes.

The rest is disciplined routine. Static rendering where the content allows it and explicit revalidation where it does not. Images served in the format and size the device asks for. Canonicals, hreflang and sitemaps generated from a single route definition, so the metadata cannot contradict the routing. A performance budget enforced in CI, so the improvement survives the next feature.

The framework moves quickly, and that is a real cost: conventions that were correct two releases ago are not always correct now. Keeping up with it is part of the work, and it is why the documentation shipped with the installed version is the reference used here rather than whatever was true last year.

The part that shows in production is not the rendering, it is where the rules live. A price calculated in the browser is a suggestion anyone can rewrite from the developer tools; the same calculation performed on the server is a rule. Next.js makes it easy to put each thing in the right place, but it does not make the decision: what gets resolved before the HTML is sent, and what genuinely needs JavaScript in the client, is still a design call. Drawn in the wrong place it produces the worst of both, a page that is slow to paint and can be bypassed anyway.