> If you have actual global state, you'll come very quickly to a point where an actual state management library beats writing your own

Which you don't have to. React has been shipping useState, useContext, useReducer hooks for quite some time now - and will get you the exact same patterns seen in Redux (if so inclined).

It's important to note that there _are_ differences in how `useContext+useReducer` behave vs how (React-)Redux works, especially around when and how components will re-render:

- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

Any large codebase should be using multiple contexts - which not only alleviates some of the performance pains but also helps in keeping the code structured (compared to one big state object that Redux recommends - unless that's changed).

Now if we're talking very high frequency updates, you'd probably keep the state in the component. That'd be faster then either approach - and such components are likely few in number.

With a lot of hand-written boilerplate, many required manual optimizations and performance that will in the best case be equal but often doesn't even get close. Context cannot rerender selectively. You change one property in a context object, all subscribers rerender, no matter if they access that property.

> are already searching for the wrong tool from the beginning

Agreed, that's why I wrote "realizing" and not "having". Some devs use Redux as a hammer when they actually need a screwdriver - they just don't know better.