Fair disclosure: I'm definitely biased towards hooks because I feel like I "get" them and would never go back. So bear with me > Hook lifecycle is implicit and

Fair disclosure: I'm definitely biased towards hooks because I feel like I "get" them and would never go back. So bear with me > Hook lifecycle is implicit and you better have the whole doc in your head. It depends on this weird array, and have a few edge cases. useEffect() will run after each render if you don't specify a dependency array. Otherwise, it will run only if any dependency in the array has === changed. That's pretty explicit to me (but I think you mean in terms of naming.. but I think one or two reads through the docs should make it explicit). The return "cleanup" function is a bit odd at first, sure, but it's really just a function that will run _before_ the next effect runs. The general recommendation is to not use the dependencies array at all unless necessary. > you need useRef() to hold the interval ID for it to work with hooks. A fact you are unlikely to realize without a hard debugging session. While a simple attribute will suffice with a class. useRef() in practice behaves almost exactly the same way as instance properties on class-based components, so I think of them as the same thing. useRef is even nicer for debugging IMO because their values are exposed in the React devtools, unlike instance properties. > spreading accross methods is actually nice: people intertwine code for various steps easily in hooks, making a mess of things I think having 5 features crammed into the same lifecycle method is far more of a mess than each feature handling their lifecycles independently. That's the point of hooks: you can wrap up functionality that's related to the same feature all in one place. IMO that's simpler to reason about and debug, but I can understand how that might trip other people up. It's sort of horizontal vs. vertical.