In Defense of JavaScript Classes

These days it feels like everyone is attacking classes in JavaScript. Developers I respect say ES6 classes are a virus. We’ve compiled long lists on the reasons that ES6 classes are not awesome. Apparently, if we’re still brave enough to try them, we need advice on how to use classes and still sleep at night.

ES6 classes: a force for good or evil?

While I appreciate these insights and concerns, I’ve been torn on this issue. Should we avoid ES6 classes since more powerful and flexible alternatives exist? After a lot of debating, I’ve decided to use ES6 classes in some contexts, albeit carefully.

Here’s why.

Fewer Decisions = Win

Even Sub-Standard Standards Have Value

If you show a team of object-oriented devs ES6 classes, they’re less likely to slap everything in one file.

Classes help sell ES6 to the long list of developers who just aren’t that into JavaScript. If classes get people interested enough to use ES6 today, that’s a win.

Low Learning Curve

Sure, functional programming is in vogue, but I see a common theme in workplaces where I’m speaking and consulting: The biggest problem I have is getting smart server-side oriented developers interested in learning anything new in JavaScript. The problem isn’t intelligence. It’s interest.

JavaScript is swallowing up so much of the developer experience that many server-side developers are being forced, kicking and screaming, into JavaScript.

These “reluctant JavaScripters” often don’t care about the two pillars of JavaScript. So if we can standardize on something familiar and approachable, we’re far more likely to get encapsulation instead of inline ES5 slapped into the global namespace. Yes, this is still extremely common.

If we want to be successful with mindsets like this, it sure helps to choose an easy, consistent, and familiar approach.

It’s Just Sugar

ES6 classes abstract away concepts like prototypal inheritance, and in doing so they offer a familiar and simple paradigm. Yes, it’s limiting. But teams with junior JavaScript developers (nearly every team has some) may initially benefit from the guardrails. And senior developers can help junior developers avoid the common pitfalls with classes like utilizing inheritance instead of composition.

Example Code

Here’s a few other notable benefits by Axel Rauschmayer

They are a standard for single inheritance. There are way too many inheritance libraries and we are already seeing some of them being replaced with ES6 classes (in Ext JS, in AngularJS 2, soon in Ember.js, to some degree in React).

Related to the previous item: they help tools (such as IDEs and type checkers) analyze source code statically.

You can subclass built-in constructors such as Error.

They are compatible with current code that uses constructors.

A Bright, Standardized Future

Cory House is the author of “Building Applications with React and Flux”, “Clean Code: Writing Code for Humans” and other courses on Pluralsight. He is a Software Architect at VinSolutions and trains software developers internationally on software practices like front-end development and clean coding. Cory is a Microsoft MVP, Telerik Developer Expert, and founder of outlierdeveloper.com.

Pluralsight Author, Principal at reactjsconsulting.com, Software Architect, Microsoft MVP, Speaker, Clean Coder, Aspiring Outlier.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store