That might be a case where you want a SPA + backend API. But the point is that in many cases you either don't need a highly interactive frontend or the frontend is not that interactive (ie. progressive enhancements work).

Ime progressive enhancements are brittle and hard to maintain. If your site doesn't need any JS it's fine, but as soon as it needs some interactivity beyond the absolute basics you benefit from having reusable components and automatic change detection / data binding.

Not true anymore, as tools like unpoly, htmx and the like make it really easy to integrate and maintain with very little dependency and no build step.

Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ

I fail to see the connection with jquery. Anyway brittle and hard to maintain is what we experience now with frontend stacks and codebases with very short lifespan. I can't keep track of components libs du jour that come and go and keep being reinvented with very little value added on each iteration, along with constant api breakage. Brittle, indeed. Meanwhile, Rails and Django have been rock solid.

Both jquery and htmx style approaches lack the concept of components, data flow, template binding etc. At most you get string templates. You end up manually wiring up dom updates when state changes, and that kind of thing is brittle and is why stuff like React was invented in the first place.

React has been very stable throughout its life time. You can run 10yo react code in v19x without issues.

The reason HTMX lacks the concept of components is because you already have components.

Components are backend logic in an SSR application. If we have some component and the associated HTML BS JS, we're good to go. Virtually all backend frameworks have components.

Whats the advantage of this? We have one component. When we use react or vue, we now have two. The backend one and the frontend one, and they're not the same component. We can kind of force them to talk together over JSON and an API.

"Islands" are really nice for this. The highly interactive pieces are usually only a small part of the app - just mount a component there if it's suitable. You don't need a full blown SPA

Islands probably have some runtime performance benefits, but the dev experience and build-time complexity is probably just as high or higher than most JavaScript SPA setups.

IMO no, because with a SPA everything has to be a SPA, which is incredibly inconvenient.

The benefit of the island is only the island has to be a SPA. The rest can be SSR.

Yes, when the thing you are building is a web application, you should use web application tools.

When you are building a data browser, you should use web tools.

It sounds nice in theory but then eventually you wind up needing to implement a feature where you wish you had React et al to implement it.

Easier just to start with it from the beginning. Assuming you're a full stack / front end guy of course, or else I get the appeal of html only.