4 ms·

Htmx is what you want for making websites. This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication. So, if yo

by mamcx 3y ago

Htmx is what you want for making websites. 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.

leptons 3y ago
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. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260 https://github.com/bigskysoftware/htmx/issues/2260
- pfraze 3y ago
  I’m guessing the issue is devs putting business logic constraints in the client and not duplicating them in the server
- Terretta 3y ago
  Actual hackers, the ones who try to hack your e-commerce site. For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.
  - leptons 3y ago
    That sounds like an irrational fear of front-end.
  - camdenreslink 3y ago
    If you do server-side rendering of your React application, then it would be very similar to htmx from that perspective. If it’s is purely a SPA, then all business logic would be behind secure APIs, so I don’t really understand your point.
- lukevp 3y ago
  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.
  - leptons 3y ago
    >SPAs require implementing safety checks on both sides in 2 different languages. 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.
  - hirvi74 3y ago
    > 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.
- Nextgrid 3y ago
  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.
  - orphea 3y ago
    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.
    - Nextgrid 3y ago
      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).

by mamcx 3y ago

leptons 3y ago

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. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260 https://github.com/bigskysoftware/htmx/issues/2260

pfraze 3y ago
I’m guessing the issue is devs putting business logic constraints in the client and not duplicating them in the server
Terretta 3y ago
Actual hackers, the ones who try to hack your e-commerce site. For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.
- leptons 3y ago
  That sounds like an irrational fear of front-end.
- camdenreslink 3y ago
  If you do server-side rendering of your React application, then it would be very similar to htmx from that perspective. If it’s is purely a SPA, then all business logic would be behind secure APIs, so I don’t really understand your point.
lukevp 3y ago
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.
- leptons 3y ago
  >SPAs require implementing safety checks on both sides in 2 different languages. 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.
- hirvi74 3y ago
  > 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.
Nextgrid 3y ago
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.
- orphea 3y ago
  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.
  - Nextgrid 3y ago
    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).