Zen and the Art of Motocycle Maintenance

I strongly prefer Elixir/Phoenix and if I can't use that, I like rails. I say that so you know my bias.

But that said, I do sometimes choose Next.js because to me the biggest problem it solves is performance by allowing doing the rendering where it makes the most sense, even within the same page. Next.js allows you to seamlessly do rendering at different points depending on requirements. For example the static portions can be rendered once at build time (SSG) and served statically. If you don't have any dynamic stuff you can just serve your whole site with nginx and not even have node in the deployed stack! You can also SSR on each request, which allows you to do compute intensive things very quickly, and allows rendering differently based on server-side information (like DB queries, etc). You can also use standard client-side rendering for stuff that fits better there. That's especially useful for menus and reactive components.

Much more accessible to frontend engineers so you can detach what would be backend problems to your frontend engineers. Often many microservices will be available but no cohesive endpoint or gateway will be available. Task your frontend with creating the gateway because they know the access patterns and they know what they need.