Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
this post was submitted on 25 Oct 2026
371 points (95.1% liked)
Programmer Humor
33844 readers
1680 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
- If the mod doesn't find it funny, you're banned. Ha-ha!... For real: do not use the community for "statements". There are other places for such content. Keep it chill and funny.
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I don't like working with them any more than you do, but they're necessary to enforce read/write-level security. Without them, there'd be no differentiation between reading a variable and writing variable from an external class, which kinda defeats the point.
From a development standpoint, they're an extra hurdle to clear. From a security standpoint, they're a necessary evil.
Moreso correctness, not security. In the end, your user is shooting themselves in their foot, if they mutate a variable that they shouldn't, and by making the variable private and only offering a getter, we document that.
Having said that, there's also big differences between languages and paradigms, though.
In object-oriented / garbage-collected languages, you often pass around references to an object into so many places that you need to code defensively versus your own codebase. That's why getters/setters were taught religiously during the height of OOP.
In other paradigms, you often just have one place that uses an object and then you can ...simply not shoot yourself in the foot there. When you control both the definition and the access, you don't need to protect yourself from yourself. In particular, you would probably think twice before mutating an object anyways.
Damn, I was gonna disagree but you bring up some good points.
I really need to get into functional programming.
Functional programming is definitely worth a look in this regard as well, but what really drove this home for me is Rust.
Its ownership+borrowing concept is exactly that, it enforces that you've got one place where an object is managed and in particular mutating can only be done in at most one place.
Obviously, there's also ways to get out of that, in case you do want some memory managed centrally, but it just isn't the default.