3 ms·
It's powerful to have your front-end library automagically run code returned by your API, sure. But you can't hand-wave the security concerns of that away by r
by davedx 3y ago
It's powerful to have your front-end library automagically run code returned by your API, sure.
But you can't hand-wave the security concerns of that away by ridiculing the people trying to discuss them.
There is a fundamental difference between your server returning data versus returning code. If you don't want to accept that, fine, it's your project, or career, whatever. But if you conduct extensive ad hominems against people (I'm not a fan of "Devrels" but jeez, that part of this post felt like blatant character assassination) instead of just debating the facts then you're a douche and no better than the people you're disparaging.
I think HTMX is an interesting project that I'll probably give a try at some point. But breathless cultish hype of it has already turned me off. I don't even know if React got this much attention!?
- aidenn0 3y agoYour server already returns code if you are running javascript on your frontend. Your server already returns arbitrary html (which can include executable code) unless you are running a fully static backend. HTMX moves where the trust boundary is a bit, but it doesn't change that it exists at all.
- couchand 3y ago> But you can't hand-wave the security concerns of that away... What security concerns, exactly? > There is a fundamental difference between your server returning data versus returning code. If my server returns a bit of something, and then my application code running in the browser takes conditional action based on that return value, was it data or was it code?
- davedx 3y agoSeriously? It’s data. Unless your client and server are Lisp
- nightlyherb 3y agoSecurity-wise, how is a server returning HTMX any different from a server returning HTML with forms? The clients both have the same capabilities, no?