I would also prefer something like Next.js with partial hydration. But what I want in that is probably a much bigger ask: I want the partial hydration to be performed automatically with static analysis. Something like Svelte (real DOM codegen, no need to ship a library to the browser) would be especially nice, but I don’t want to give up JSX. In the end, this is probably well outside the scope of a framework coupled directly with React, and I suspect that if I want it badly enough it’s something I’ll need to build myself.

I'm not sure if we're saying the same thing, by partial hydration I mean only wiring some specific client side components for interactivity. As in only shipping the react components over the wire that need to be rendered on the client for user interaction. Meaning the overall page is vanilla HTML, but some subtrees are React wired components. Complete with state management that can work between all of them. In which case I'm thinking it would be fine to mark components individually as server/client.

Yes, that was what I meant as well. But as I’ve read about the approaches currently available, all of which require manually opting in per component, I’ve had two thoughts:

1. Manually marking a component for hydration likely means shipping the whole structure below as JS, which may hit diminishing returns fairly quickly.

2. At least if you’re using TypeScript, enough is known (or could/should be) to determine which components are truly static. Next.js already has a rudimentary version of this. That kind of analysis could be a huge DX improvement.

I am currently working on projects with Django (jinja2), Laravel (blade), Node (ejs) and Next. I can't possibly understand how so many people in this thread are preferring server rendering frameworks. As soon as you have a non hello world application (= complex state shared across multiple components / page) a SPA application is so much easier and productive. And Next brings this experience back to public facing frontends because it supports prerendering along other things.

Isn't SSR (or even better SSG) the M in JAM? It's a marketing term anyway and it doesn't really need to "lose", we can just talk about the technologies instead.

Next.js gives you a great toolbag to choose from for each challenge, it's definitely going to stay around and keep growing like crazy.

I believe the M is static HTML, not dynamic SSR HTML

I thought so too.

JAMStack is Next.js with SSG+CSR.

You can use much of the J and the A during the SSG stage that then delivers the M to the user. And very user-specific and/or dynamic things will have to remain some sort of generated shell and the content fetched on the client anyway.

JAM has other problems. I don't think that's one.