Seems that HTMX requires unsafe-eval?
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.
For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.
If it’s is purely a SPA, then all business logic would be behind secure APIs, so I don’t really understand your point.
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.
Nodejs is quite popular. One language works on front-end and back-end. Like any language, security is up to the developers.
>Many junior devs believe the client code is trustworthy and put important validation only in the client.
Who is letting "junior devs" make these decisions? It sounds like they deserve to be hacked.
This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication.
So, if you are serving HTML, then htmx.
When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop).
(and in short amounts like creating complex widgets like maps, selects, etc).
---
I work for eCommerce, and there is terrible to use React: It is too easy to make "hacker-friendly" websites when using it: INSTEAD, you MUST validate, format, process, render, and display all on the server side.
For me, I retain all the logic on Rust, display HTML, and just put some extra interactivity with htmx, that because at the server-side is the same as without, means I CAN'T INTRODUCE A SECUIRITY BUG.