"No new functionality" and "nothing new" are two different things. Improved developer experience, decreasing the surface area of bugs, etc - all examples of definite improvements that are not technically new functionality.

And what do you think React can do that jQuery cannot? Heck, what do you think React can do that standard HTML5/JS API cannot do?

React doesn't offer new functionality to do UI. It offer new ways to think about the problem.

Hooks doesn't offer any new functionality over `this.state` and component life cycle, it offser new way to think about the problem.

> And what do you think React can do that jQuery cannot?

Again, you've missed the point.

How did you extract concerns from class components and reuse them previously? Easy and hygienic extraction and composability of concerns literally is something new enabled by Hooks that was not offered by class components.

You're also misrepresenting what the docs say about replacing class components. They're saying that you don't need to replace class components just for the sake of using 'the new thing'. However if there was some concern you wanted to extract from a class component that you could not previously, you absolutely could adapt it to use hooks, and then extract and reuse that concern in another component.

> The docs actually state quite clearly that developers are discouraged from replacing class components with function components.

Could you link to where it says this? My understanding is that hooks are intended to be the new best practice, and ideally all code would use hooks (which the React team believes are overall better than class components), but the React team doesn't want to force migration pain on everyone. So as I understand it, it's not that a class -> hook refactor is "discouraged", it's more "don't let this be too much of a distraction, and don't feel obligated to rewrite old code".