3 ms·

I don't think it's productive to throw out enotionally-charged words like "fanatical" and "infantalize" in these conversations. There are many valid complaints

I don't think it's productive to throw out enotionally-charged words like "fanatical" and "infantalize" in these conversations. There are many valid complaints to make about React hooks, but I'm not really seeing those here. And I'm not seeing evidence that you've crossed chesterton's fence with them either. I'll criticize hooks all day, but for all their footguns, they provide a level of abstraction (and a simplicity of implementation for it) that's really hard to argue with. They let you break up reactive stateful code in maybe the most scalable way I've ever seen, and their contract with the outside world allows for some crazy optimizations on the framework's part. I think the team is onto something really special here Of course they're also easy to misuse, and they can be really "magical" until you fully grasp them. Those are problems the ecosystem will have to grapple with (and I know the core team is aware of them). Though the "magic" at least is due more to weirdness and inversion of control than it is to actual complexity. Having a grasp on how they work, I feel like I wouldn't have too much trouble implementing a basic version of the same system myself, because the primitives are ultimately not very complicated I believe hooks are really good bones for building UIs, and I think they'll last because of it, even though the surface developer experience has some warts for now

andrewmcwatters 4y ago
I think it's sufficient to say that having been exposed to hundreds of thousands of lines of code across different industries and programming languages, I don't like React Hooks, and I don't even like them repurposing the word "hook" which is otherwise known as a trampoline in other programming language contexts. React Hooks, if anything should have just been called React Callback Queues. As for emotionally charged words, maybe it's not appropriate in the current zeitgeist to post without some degree first of self-censorship, but it's how I feel, so I'm going to say it. React Hooks were fanatically adopted, in my opinion. Side effects are a regular part of programming. I find it, thusly, infantilizing to hide those details. I wish people would stop this sort of thing, but if you want to say your part and that's how you feel, say it too. Edit: You've apparently even been downvoted for expressing this sentiment, which I hate on HN, because it's how you felt. I wish social sites wouldn't do this. No one should be able to invalidate that.
- brundolf 4y ago
  > React Hooks were fanatically adopted, in my opinion It was one of those things where the ecosystem had to be unified, because a fractured ecosystem would have died. The React team said "this is the way we're going", and people followed along not because they were fanatical, but because that's the path that was set out. We can debate whether hooks were the right call for the core team to make, but I think it's incredibly uncharitable to say every library author who went along with it was just being "fanatical" > I find it, thusly, infantilizing to hide those details Software development is all about hiding details. The key is picking the right details to hide and not hide. Hiding details (ideally) lets users focus on the parts that matter to them, and gives the compiler/framework/system room to optimize the rest. In React's case, we got features like automatic batching (https://react.dev/blog/2022/03/29/react-v18#new-feature-automatic-batching https://react.dev/blog/2022/03/29/react-v18#new-feature-auto...) and concurrent mode (https://react.dev/blog/2022/03/29/react-v18#what-is-concurrent-react https://react.dev/blog/2022/03/29/react-v18#what-is-concurre...) for free, without having to modify application code, because the application code was already abstracted enough that the framework could significantly change how it did things behind the scenes without changing the contract In terms of developer experience: I consider myself to have a fairly deep understanding of the browser platform, and a fairly-complete understanding of how hooks "really" work, and I'm still glad that I have React's abstraction layer most of the time when doing real work at my job. There are escape-hatches, as there should be, and the rest of the time I'm really very happy not to have to fiddle with all the bits when I just want to render another form and implement some business logic. I don't feel the least bit infantilized. There are things I don't love about hooks - mainly that they do things which should really be language-level features, and that causes some dissonance - but here's what I love about them: They expose a tiny set of primitives - pretty much just useState and useEffect (useMemo, useCallback, and useRef can be implemented in terms of these!) - which plug directly into the simplest, smallest side-effect-y things we need to be able to ask the React framework to do for us. And then, because these state and side-effects primitives have their own reactivity baked in, we can compose them into larger stateful/side-effect-y abstractions which also have their own reactivity baked-in (unlike classes, unless those classes are full React components). We can build amazingly high-level, convenient abstractions on top of this amazingly minimal set of reactive primitives, which will always themselves be reactive, no matter what. And then the framework can break them back down into the primitives at runtime (in fact, it never sees anything but the primitives), and schedule and re-order and do all kinds of nifty stuff with them without breaking contract, because the contract is tiny and elegant. In my experience that's unique and beautiful.

andrewmcwatters 4y ago

I think it's sufficient to say that having been exposed to hundreds of thousands of lines of code across different industries and programming languages, I don't like React Hooks, and I don't even like them repurposing the word "hook" which is otherwise known as a trampoline in other programming language contexts. React Hooks, if anything should have just been called React Callback Queues. As for emotionally charged words, maybe it's not appropriate in the current zeitgeist to post without some degree first of self-censorship, but it's how I feel, so I'm going to say it. React Hooks were fanatically adopted, in my opinion. Side effects are a regular part of programming. I find it, thusly, infantilizing to hide those details. I wish people would stop this sort of thing, but if you want to say your part and that's how you feel, say it too. Edit: You've apparently even been downvoted for expressing this sentiment, which I hate on HN, because it's how you felt. I wish social sites wouldn't do this. No one should be able to invalidate that.

brundolf 4y ago
> React Hooks were fanatically adopted, in my opinion It was one of those things where the ecosystem had to be unified, because a fractured ecosystem would have died. The React team said "this is the way we're going", and people followed along not because they were fanatical, but because that's the path that was set out. We can debate whether hooks were the right call for the core team to make, but I think it's incredibly uncharitable to say every library author who went along with it was just being "fanatical" > I find it, thusly, infantilizing to hide those details Software development is all about hiding details. The key is picking the right details to hide and not hide. Hiding details (ideally) lets users focus on the parts that matter to them, and gives the compiler/framework/system room to optimize the rest. In React's case, we got features like automatic batching (https://react.dev/blog/2022/03/29/react-v18#new-feature-automatic-batching https://react.dev/blog/2022/03/29/react-v18#new-feature-auto...) and concurrent mode (https://react.dev/blog/2022/03/29/react-v18#what-is-concurrent-react https://react.dev/blog/2022/03/29/react-v18#what-is-concurre...) for free, without having to modify application code, because the application code was already abstracted enough that the framework could significantly change how it did things behind the scenes without changing the contract In terms of developer experience: I consider myself to have a fairly deep understanding of the browser platform, and a fairly-complete understanding of how hooks "really" work, and I'm still glad that I have React's abstraction layer most of the time when doing real work at my job. There are escape-hatches, as there should be, and the rest of the time I'm really very happy not to have to fiddle with all the bits when I just want to render another form and implement some business logic. I don't feel the least bit infantilized. There are things I don't love about hooks - mainly that they do things which should really be language-level features, and that causes some dissonance - but here's what I love about them: They expose a tiny set of primitives - pretty much just useState and useEffect (useMemo, useCallback, and useRef can be implemented in terms of these!) - which plug directly into the simplest, smallest side-effect-y things we need to be able to ask the React framework to do for us. And then, because these state and side-effects primitives have their own reactivity baked in, we can compose them into larger stateful/side-effect-y abstractions which also have their own reactivity baked-in (unlike classes, unless those classes are full React components). We can build amazingly high-level, convenient abstractions on top of this amazingly minimal set of reactive primitives, which will always themselves be reactive, no matter what. And then the framework can break them back down into the primitives at runtime (in fact, it never sees anything but the primitives), and schedule and re-order and do all kinds of nifty stuff with them without breaking contract, because the contract is tiny and elegant. In my experience that's unique and beautiful.