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.
> 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 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 React's case, we got features like automatic batching
It's truly amazing how React team manages to present leaky abstractions as something that community should celebrate. Or maybe what's amazing is that community is gullible enough to buy that. That's exactly the fanaticism your opponent is talking about.
Batching isn't a new feature (it's also not a React-specific feature). Looks like batching became more fragile with hooks, so they had to fix it later.
But of course React team doesn't call it a bugfix. Meet a new feature: "Automated Batching". Great marketing.
It seems like you're saying that benefit of hooks is that they made it possible to solve problems caused by hooks.
Which actually rings true: I found that React folks absolutely love solving problems, and they love React precisely because it provides a never ending source of solvable engineering problems.
Of course, since your engineers will always be busy with engineering problems, they will have very little time for product problems. So your product will suffer, but at least your engineers will be happy. They get to talk about so many cool things: immutability, hooks, batching, concurrency, memoization (ironically, the opposite of hiding the details). Given how expensive engineers are, it might be a fine tradeoff for some companies, though I personally would never want to work in those.
Also, after taking a quick look at Dan's post on batching, it seems like their solution is a great example of leaky abstraction. Their intention was to batch rendering, but they implemented it by batching state updates. Which means you can't expect to read the new state right after you set it. As far as I remember, both Vue and Svelte also implement batching, but they don't suffer from such counterintuitive behaviors.
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.