Yes, the inclusion of dissenting opinions is valuable, to a point. Until you turn your back on truth, reality, and widely accepted best practices. At that point it becomes reckless and foolish.

Sometimes the “dissenting opinion” is really masking ignorance of the topic. Sometimes it’s simply, provably wrong.

Is it useful to hire an accountant who thinks $2 + $2 = $22?

No, absolutely not, because you’d spend way to much time and money fixing their mistakes.

Likewise, it isn’t a good idea to hire somebody who refuses to participate in code review (each hour spent in code review saves 33 hours in maintenance) or TDD (which reduces production bug density 40% — 80%).

There is concensus in the OOD community that we should favor composition over class inheritance. It’s one of the foundational axioms of the Gang of Four’s “Design Patterns” book, and a common refactoring technique (See “Refactoring” by Martin Fowler et all.)

The voices that do disagree with me do so primarily on the grounds that “dissenting opinions” are important and that people like me should not be telling people what not to do. Then they flounder with style preferences or misconceptions when I challenge them to defend class inheritance.

In this case, there’s a clear causal relationship between runaway class taxonomies and project success/failure.

I’m saying that there’s a safer road that also happens to be much simpler in JS. Composition is hard in Java, which is perhaps the main reason class inheritance survives. There is a clear winner in JavaScript.

It’s become the dominant way to structure applications in React via function composition of higher order components. Inheriting from your own components is explicitly discouraged for all the reasons I’ve spelled out countless times before.

Composition is widely accepted best practice in the industry.

Your objection (which boils down to “don’t tell me what to do”) seems to be the only one that remains.

Absent a valid reason to use class inheritance, it’s a weak argument.