Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX.
SPAs require implementing safety checks on both sides in 2 different languages. Many junior devs believe the client code is trustworthy and put important validation only in the client. I’ve worked with many codebases like this. If there’s only one place to specify validation, it should always be the server. So server side frameworks have this built in to their model and thus are less susceptible to this whole class of bugs.
> SPAs require implementing safety checks on both sides in 2 different languages.
This isn't exclusive to SPAs. For example, I am a .Net dev, and I have both front-end and back-end validation in most of my applications without ever using any SPA frameworks.
If I am in a pinch for time, I sometimes just drop front-end validation completely, and let the server handle the validation and then have the front-end handle the server validation responses accordingly.
Nothing specific to React but having both client-side and server-side validation means that any deficiencies of server-side validation will be concealed and go unnoticed (until exploited by an attacker).
In contrast, server-side validation only means any validation deficiencies are more likely to be discovered during legitimate usage since the client-side validation is no longer covering up for it.
I think you have it backwards. You _first_ do server-side validation, then you add client-side validation _as an optimization_, so that invalid requests are not even sent.
My point is that once you do that any subsequent deficiencies in your server-side validation become invisible during normal usage (because the client-side validation will prevent you from even trying).