Comment by LAC-Tech
A front end web framework with global state management should be a last resort for a website. Coming out of the gate with it is just ridiculous IMO. Most peoples websites are just not that complex.
There's like an escalation ladder in my mind:
- just write HTML
- statically generate the HTML
- dynamically generate the HTML
- dynamically generate the HTML at a smaller granularity (HTMX et all)
- augment your HTML with custom web components that have client side behaviour.
Only if you've exhausted that should you bother with something like React. And even then SolidJS does a much better job of it than react itself does.
So yeah, I am just not seeing it. Former (and perhaps future!) React.JS dev btw.
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.