That gist looks like a bit of a list of strawman arguments to me. Most of those have never occurred to me, but lets look at one that has

"Stale closures in Hooks are confusing"

Seb gives an example under that section that they call confusing. I don't understand why. The syntax makes it very clear when the values are checked - if its in a closure, its clearly at the time of the click - if its not in the closure, its clearly at the time of rendering, so no, they are obviously not equivalent.

The problem with React hooks is that they behave very differently from all normal JS code. In normal code, most functions that contain closures in them run once and the closures run zero or more times (depending on the consumer of those closures). In React, the render function runs many times, but the inner hook closures run a different (could be smaller, equal or greater) number of times, where that number may depend on the number of times render runs or the number of times other closures run.

You can easily create a mess this way; React realized this, which is why the official documentation recommends not modifying state from within useEffect. But current frameworks (e.g. Remix) already do this, and this already causes problems with batching (see https://twitter.com/oleg008/status/1680290734644002816). Additionally, dependencies between multiple useState and useEffect calls can easily be non-obvious - they may be embedded within custom hooks.

In a mutable / signal based framework that really pays attention to all these details (like MobX) there is a consistent way to how things work based on a relatively simple dependency tracking mental model (MobX based signals can be implemented in about 50 lines of code if we're willing to forego the nice proxy syntax). So not only is state management way easier, its also on average less prone to these kind of issues.

In essence, React state managements makes things harder with the promise of making state easier and more consistent to manage long term, but doesn't really succeed in delivering on that promise. At least not when compared to more newer interations of mutable reactive state management (like MobX) which support all the goodies (automatic dependency tracking, automatic batching, automatic disposal of unobserved state and computed values etc)

> The problem with React is that behaves very differently from all of your code. With most functions that contain closures with them, the function when called runs once and the closures run zero or more times.

I don't think I agree with that generalization. I probably could not even make a generalization about what normal closur-ing does or should look like.

> In a mutable framework that really pays attention to all these details (like MobX) there is a consistent model to how things work. So not only is state management way easier, its also on average less prone to these kind of issues.

My experience with MobX and the greater observable-industrial-signal-complex is that accidental loopiness very much can and does still happen. I have seen codebases with complex MobX computed-changes-graphs that senior engineers were clever enough to write but not to debug. And I was not aware of tooling which helped keep these graphs in line.

That said, I agree React's hooks have friction to them. I just tend to be in the camp of "I prefer my computational change graphs to be gated by a bit more boilerplate".

Forgot to add this:

> I probably could not even make a generalization about what normal closur-ing does or should look like.

I would say the key reason why this looks so wrong is that it essentially breaks lexical scope. The closures "look like" they are the same values from the scope above, but they are actually values from previous runs.

I would be hard pressed to find another library API that breaks lexical scope reasoning for its closures in such a way.

> My experience with MobX and the greater observable-industrial-signal-complex is that accidental loopiness very much can and does still happen. I have seen codebases with complex MobX computed-changes-graphs that senior engineers were clever enough to write but not to debug. And I was not aware of tooling which helped keep these graphs in line.

My experience is completely the opposite. I've worked on large, complex interactive editors writtein in MobX and its been pleasently easy to reason about. Some tooling is built into the framework (cycle detection, strict mode). The design guides you towards making the right choices (prefer computed over autorun, etc) and makes those choices easy to use.

And unfortunately, with useState, useMemo and useEffect you can make the same cyclic dependency spaghetti (e.g. useEffect can easily setState). Unlike with MobX however, everything is harder.

Huh interesting, do you happen to have a link that goes into cycle detection? If it comes with MobX out-of-the-box, I can say that it did not seem to have kicked in for our use cases (but maybe it's an opt-in?)

I think its always been built in, but pertains to `computed` values only. Its still possible to create cycles but you need to combine `autorun`, timers/nextTick/similar and actions to do it - definitely not something thats needed in most code.

Some other methods for tracing and debugging complex graphs are described here https://mobx.js.org/analyzing-reactivity.html

Neat, thanks for the link!

I vaguely remember my colleague having a reason for why his abstraction did not fit in the computed box. Probably something related to async, so it might very well have been because of that

What do you mean by:

> Quoting Alex Russel suggests you are more interested in heat than light

I know he's said a lot of harsh things about frameworks like React, Css-in-js, etc, but I've read all of them from the perspective of "these things are hurting the UX a lot more than you think".

I'm right now only finding this one, not sure if some older tweets are gone. I remember him as someone who does more anti-marketing than furthering discussions.

https://twitter.com/slightlylate/status/1595328476956876800

I just see him stating an opinion? It’s a valid one.

I had a PM suggesting we move from using git to dropbox because github is "hurting the UX".

Honestly, if that's what the research shows I think that needs to be considered. It'd be healthy to challenge those claims, and engage with how and why your revision control tool is hurting UX.