A Simple Challenge to
Classical Inheritance Fans

by Eric Elliott

“When there is freedom from mechanical conditioning, there is simplicity. The classical man is just a bundle of routine, ideas and tradition. If you follow the classical pattern, you are understanding the routine, the tradition, the shadow — you are not understanding yourself.”
~ Bruce Lee

For years I have been warning that class inheritance is dangerous, and that JavaScript offers much better alternatives based on composition, prototypal OO, and functional inheritance.

Yet many brilliant people choose to use `class` and teach it to new developers as THE WAY to handle objects in JavaScript. It reminds me of a brilliant talk:

Keep an Open Mind

I believe that developers should always be on guard against stagnation. If we think we know all the answers, we are not open to trying new things, and that could be locking us out of tremendous opportunities to evolve our programming styles and techniques.

We need to challenge ourselves constantly. If something new comes along, we should not reject it out of hand. We should be open to exploring and learning.

We should take a long, hard, objective look at the topic and question ourselves.

“Is there something there that I’m missing?”

For the past few months, a small community has been hard at work on a new way to freely compose factory functions in JavaScript. It’s called The Stamp Specification. Yet another great alternative to classes.

Always Questioning

It may come as a shock to readers of my work, but I still have an open mind about `class`. I’m still curious. Asking the questions:

So far, I have not found the answers.

I’ve issued that challenge to readers of my work. The challenge has been published on blog posts read by hundreds of thousands of people. In talks seen by tens of thousands. But all I hear are the same pack of common misconceptions.

I have thought long and deep about these topics, and contributed to hundreds of applications written in a wide variety of styles. For several years in the beginning of my career in C++ and Java, we all fully embraced class inheritance, after all, class was the only practical way available to us using the tools we had.

We all had the famous Gang of Four “Design Patterns” book on our desks, a constant reminder from the seminal work on object-oriented design:

“Favor object composition
over class inheritance.”

That advice was not controversial. It was common knowledge.

We used classes because we were forced to use classes by arbitrary constraints inherent in the tools we used.

That is not true in JavaScript.

In JavaScript,
classes are more complicated
than factories & composition.

I have been on both sides of this issue, and looked carefully at this problem from every angle I know how, because it makes a really big difference.

Ask yourself: “Have I challenged myself this way? Do I really know what I think I know for certain?”

The Challenge

Find a compelling case in code where `class` is clearly a better choice than composition, modules, or prototypal OO available to JavaScript developers. Write source code implementations written both ways.

Publish it on a blog that allows comments. Then read those comments and carefully consider the opinions.

This isn’t about who’s right or who’s wrong.
It’s an exercise for yourself.
An opportunity to learn.

If you can’t think of a compelling use case where class is a better option than composition, I challenge you to embrace Douglas Crockford’s advice:

“If a feature is sometimes dangerous,
and there is a better option, then
always use the better option.”
~ Douglas Crockford

Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript Universal App Development with Node, ES6, & React”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.

He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.