[e_y_]

To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query.

For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick.

There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.

[apsurd]

fwiw i've never experienced the drawback of separate languages for server and client. nor did i ever experience the benefit of single language across server and client.

being forced to use javascript on the server sounds like a cruel joke vs a benefit. I mean just simply from "i can literally pick anything for my controlled server env" vs "no we're a js shop cuz web"

edit to add: is it one repo? or maybe shared types. typescript is probably the strongest argument. can enforce integrity truly across the stack. but i don't think that's worth being forced into js environment and packages. community is forced to reimplement everything in js. no good.

[marcosdumay]

HTML templates and the shadow DOM solved the only problem of separated languages that I have ever actually seen.

So yeah, once there was a benefit for using the same language. IMO, it never was worth the cost. But it doesn't exist anymore anyway.