4 ms·

> And as a side note: can we please stop shitting on every React post that appears on HN? All this hater energy is really starting to be a drag. Kind of ironic

> And as a side note: can we please stop shitting on every React post that appears on HN? All this hater energy is really starting to be a drag. Kind of ironic when this post kicked off a long argumentative thread shining a light on the exact things people don't like about React... "escape hatch", "impure side effects", "useEffect... huge point of failure... it sucks", arguments whether hooks and refs are immutable or not... and these comments are coming from people who claim to like React!

localghost3000 4y ago
I know. A bunch of dudes talking out their ass about me calling useEffect an escape hatch when it’s literally called that IN THE DOCS. HN never disappoints.
- diordiderot 4y ago
  I don't have a dog in this fight but I think that people here don't care so much about what is said, more about what is shown. E.g. an outspokenly pro-climate politician who passed the 'frack through orphanages with baby seals bill' will not be taken seriously because actions don't match reality. IIRC useEffect was not originally called an escape hatch and that terminology was pegged on once they realised that a fundamental hook was actually a 30mm footgun. To make it worse they haven't provided a clear way to deal with the problem instead relying on 3rd party packages
  - localghost3000 4y ago
    You’re conflating clarifying intent with outright deception. The react team is trying to clarify how useEffect is intended to be used because it’s so frequently misused. The fact that it’s a possibly a poorly designed abstraction that is ripe for misuse is not really relevant to the discussion imo. Don’t take my word for it though. Dan Abramov himself has said pretty much what I’m saying (you’d have to find it on Twitter). Ken C Dodds shared a talk (not run by him) called “Goodbye UseEffect”. Look this stuff up if you haven’t. It’s out there. There are often better ways than useEffect. And when those don’t work you can always use the esc… well you get the idea. EDIT: spelling
ojkelly 4y ago
The purest form of function programming cannot have side effects. But to do anything useful you need them. So like many other functional programming langs/libs/frameworks react had a controlled means to run side effects. That’s the escape hatch of useEffect. It’s not a bad thing. It’s thematically same as the unsafe block in Rust. It allows you to reach out of the main paradigm, when required.
- marcosdumay 4y ago
  React was the thing that convinced me that you can't have a non-pure reactive system. React is complex because views aren't pure; slow because it has to rerender things that didn't change, because it doesn't actually know what changed, because views are impure; hard to program because impure views create bugs that even that extra complexity can't fix; and has all those escape hatches to change execution time and memoize things because the execution time actually has semantic value. And that's react, that incredibly well designed thing with incredibly knowledgeable authors, that made a huge effort to think about every problem. Non-pure reactive systems just do not work.
  - jeffreygoesto 4y ago
    Quite similar to build systems. Same arguments lead to Bazel...
  - vanviegen 4y ago
    We've had great results from our custom built non-pure reactive system (which predates React by a couple of years). The idea is to have an Observable object that can store arbitrary trees of data (each itself an Observable). UI drawing is generally split into a function call for each DOM element that has children. These functions are executed such that they track the use of observables and will be rerun when they change. I've more recently, after having suffered React and friends, started creating an Open Source implementation of the pattern we used. Currently, it's mostly still lacking in documentation and marketing, and that's unlikely to change if I'm honest. But this should give you an impression if you're interested: https://github.com/vanviegen/aberdeen/blob/master/examples/tic-tac-toe/tic-tac-toe.js https://github.com/vanviegen/aberdeen/blob/master/examples/t... Curious to know your thoughts about this being an effective non-pure reactive system.

localghost3000 4y ago

I know. A bunch of dudes talking out their ass about me calling useEffect an escape hatch when it’s literally called that IN THE DOCS. HN never disappoints.

diordiderot 4y ago
I don't have a dog in this fight but I think that people here don't care so much about what is said, more about what is shown. E.g. an outspokenly pro-climate politician who passed the 'frack through orphanages with baby seals bill' will not be taken seriously because actions don't match reality. IIRC useEffect was not originally called an escape hatch and that terminology was pegged on once they realised that a fundamental hook was actually a 30mm footgun. To make it worse they haven't provided a clear way to deal with the problem instead relying on 3rd party packages
- localghost3000 4y ago
  You’re conflating clarifying intent with outright deception. The react team is trying to clarify how useEffect is intended to be used because it’s so frequently misused. The fact that it’s a possibly a poorly designed abstraction that is ripe for misuse is not really relevant to the discussion imo. Don’t take my word for it though. Dan Abramov himself has said pretty much what I’m saying (you’d have to find it on Twitter). Ken C Dodds shared a talk (not run by him) called “Goodbye UseEffect”. Look this stuff up if you haven’t. It’s out there. There are often better ways than useEffect. And when those don’t work you can always use the esc… well you get the idea. EDIT: spelling

ojkelly 4y ago

The purest form of function programming cannot have side effects. But to do anything useful you need them. So like many other functional programming langs/libs/frameworks react had a controlled means to run side effects. That’s the escape hatch of useEffect. It’s not a bad thing. It’s thematically same as the unsafe block in Rust. It allows you to reach out of the main paradigm, when required.

marcosdumay 4y ago
React was the thing that convinced me that you can't have a non-pure reactive system. React is complex because views aren't pure; slow because it has to rerender things that didn't change, because it doesn't actually know what changed, because views are impure; hard to program because impure views create bugs that even that extra complexity can't fix; and has all those escape hatches to change execution time and memoize things because the execution time actually has semantic value. And that's react, that incredibly well designed thing with incredibly knowledgeable authors, that made a huge effort to think about every problem. Non-pure reactive systems just do not work.
- jeffreygoesto 4y ago
  Quite similar to build systems. Same arguments lead to Bazel...
- vanviegen 4y ago
  We've had great results from our custom built non-pure reactive system (which predates React by a couple of years). The idea is to have an Observable object that can store arbitrary trees of data (each itself an Observable). UI drawing is generally split into a function call for each DOM element that has children. These functions are executed such that they track the use of observables and will be rerun when they change. I've more recently, after having suffered React and friends, started creating an Open Source implementation of the pattern we used. Currently, it's mostly still lacking in documentation and marketing, and that's unlikely to change if I'm honest. But this should give you an impression if you're interested: https://github.com/vanviegen/aberdeen/blob/master/examples/tic-tac-toe/tic-tac-toe.js https://github.com/vanviegen/aberdeen/blob/master/examples/t... Curious to know your thoughts about this being an effective non-pure reactive system.