[Skinney]

How?

Everything served under one domain doesn’t have to use one technology.

Use backend rendering when you can, use HTMX where you need a little bit more, use React on the actual bits where it matters.

As a side-benefit, the React bits might end up less complicated as React doesn’t need to handle every single use case.

[snorremd]

Indeed. In a publishing (Wordpress) like solution maybe you would use HTMX for the user facing parts and React or something similar for the more interactive admin parts. Then you don't need to bother with server side rendering for the admin bits, which at least I think simplifies React a great deal. It's not that the JS fullstack frameworks doesn't handle server side rendering and routing for you, but they feel very much like black box magic to me. Especially the new fangled React Server Components with the whole serialization and streaming model.

Good old server side rendering is simple in Rich Hickey's "Simple Made Easy" way. You can build more complex logic on top of a standard server rendered model, but the base model is mostly dead simple to reason about. I like that. I've built web "apps" in AngularJS, React, Reagent (ClojureScript) and Next. So I'm not coming at this from a grumpy "backender" position. I'm coming at this from having done lots of frontend stuff and finding the frameworks becoming increasingly complex beneath the surface. It feels like they are targeting the "easy" in Rich Hickeys parlance in the sense that you don't have to write a lot of code to make something fancy. But reasoning about the behavior and what actually happens in the framework when something doesn't work is increasingly difficult.

Edit: And maybe this is a "skill issue". If you just learn the framework and library well enough you'll get by much better. But I tend to not want to bind myself to any single framework too much. So simple frameworks that don't churn too much is better for me.