At first, it felt to me that the broad stroke criticism of React expressed in this post was of the very familiar type that’s been around prob sky since it’s fir

At first, it felt to me that the broad stroke criticism of React expressed in this post was of the very familiar type that’s been around prob sky since it’s first release: that React should be more than what it’s ever intended to be, which is a library that outputs UI as a function of state (input via props). By offloading the responsibility for all the rest of it, e.g. managing state, remote fetching, etc. onto the person implementing it, React has always left a lot of room for frustration and poor decisions. But I think the criticism here is a bit sharper and more pointed than that. The author isn’t expecting Reach to do something for which it was never intended, I think. Instead, they’re saying that the abstractions (hooks in particular) that have evolved over time expose unhelpful interfaces that either conceals too much information, encourage poor patterns that lead to bugs, inefficiencies, etc. In other words, the criticism isn’t of React’s explicit decision to offload responsibility outside the scope of outputting UI, but rather that it’s evolved to make handling of those responsibilities more challenging. I think that’s a bit more serious than the former critics and worth at least considering. For my part, I’ve found little substantive advantage to hooks and do think they hide a lot of bugs by making implicit things that should probably be (and, once upon a time, were) more explicit.