Personally I appreciate the ideas behind hooks, but the implementation feels like I’m trying to write in a different language behind JavaScript that has its own rules about scope, flow control, variable dependencies, and many other things that run counter to what appears to be happening on the JavaScript surface.

I’ve worked on many projects that implemented object-oriented programming in C, and the impedance mismatch there was much more tolerable. That should be a warning signal that something is amiss with hooks in JS.

They made an embedded language extension for JSX. Why not a similar separate language for hooks, to clearly delineate when you’re working with the React state machine rather than ordinary JS state?

I was able to grasp hooks after an initial distaste. But once I started hearing about hydration, I just felt this…weariness. It’s why I’ve never been interested in NextJS and definitely not interested in RSC.

I’m open to having my mind changed, but I really don’t like having abstractions cross the network boundary.

> Definitely feels like complex implementation details leaking upwards and influencing the public API.

This describes it very well. I recently started writing React code after using Vue 3's composition API for a long time, and it's hard to explain just how much more low-level and manual the primitives feel.

When hooks were first announced they had a bit of a "you probably shouldn't use this unless you're framework author" air to them.

I'm not sure if it was the react team adjusting the message and pushing for hooks in user code, or users throwing hooks at every problem when that wasn't recommended, but it definitely got odd track.

I still like hooks for internal code in libraries and frameworks, but they ruin client code IMO. Unfortunately hooks are here to stay and there's really no way to avoid them in most apps today.