[littlecranky67]

Why is performance always argument No. 1? The true rule is, code must be readable and maintainable first. THEN, if there are performance issue with the code (no theoretical ones, you HAVE to have a real-world profiling report of YOUR code in your hands when you argue about performance), you can refactor for performance.

[mst]

A thing I remind myself of regularly: Avoiding worrying about optimisation up front too much is not avoiding caring about optimisation at all, it's reserving the number of hours you can expend on optimisation until you have enough working to have a profile available, because you are inevitably going to be wrong about which part is actually slow until that point so your optimisation hours budget will be better spent with a profile in hand.

There's a parallel here to "no, you did not find a bug in the compiler". Yes, ok, once every five years or so I actually did find a bug in the compiler, but assuming you aren't that smart is still a far far better default approach.

[ricardobeat]

That's a straw man argument - I did not say it's concern #1, just pointing out that React forces that specific trade-off. Balancing complexity, maintainability, AND performance is really hard with hooks, the lack of built-in reactivity and inefficient baseline behaviour. It's rarely a matter of "just combine it into one reducer".

On top of that, profiling and optimizing a real world application with a dozen hooks in every component is pretty painful.