Counterpoint: classes are a great way to bundle state and logic - which is exactly what UI components are - and components models should use classes more, not less.

React's "functional" components are simply poor approximations of classes. Instead of easy to read and reason about class fields, you put state in useState() function classes that are effectively named by their appearance order in source and who's current state you can't introspect with dev tools!

The component function mixes one-time setup (which should be a class constructor) with repeated render calls (which should be a method), so those of course have to be separated by putting the one-time work inside of a closure inside of the repeated should-have-been-a-callback function. Event listeners and other callbacks are another huge mess. Don't forget useMemo() or useCallback() (but which?).

It's actually quite mad.

And the differences between classical and prototypal inheritance basically don't even pop up under normal class usage in JS: just use class fields, don't mess with the prototype chain, and don't dynamically add or delete properties - all things that are how classical inheritance works - and things just work like you expect.

They're modeling reactivity, not classes. It's a well established pattern in functional programming

The one time setup mixed with repeated render calls is odd, but it's a design decision they made. It reduces boiler plate, though I don't necessarily agree with it because it is a leaky abstraction