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.
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
Many developers have only been coding a couple years (and due to rapid industry growth, this isn’t changing anytime soon). So consistency is key to assure clarity. In a world with ES6 classes, how many new JS developers will take the time to learn the merits of alternative patterns? JavaScript already has an overwhelming ecosystem of build tools, libraries, and frameworks. Is it realistic to expect developers to choose between the factory pattern, revealing modules, prototypal inheritance, higher order components, stamps, and so on based on context? ES6 classes provide a standardized default decision which helps developers focus on solving business problems.
Even Sub-Standard Standards Have Value
Throughout the years we’ve seen half a dozen ways to encapsulate logic in JS. IIFE’s, revealing modules, AMD, CommonJS. Classes finally give us a clear, standardized way to structure our code. Nearly every JavaScript codebase I’ve inherited has suffered from a lack of consistency. One file will use prototypes. The next file will use the revealing module pattern. And many will simply place all logic in the global namespace. Classes aren’t ideal, but they’re a familiar and attractive option for problem decomposition.
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
If you’re working on a team that already understands classes, then ES6 classes are clearly easier to understand than the alternatives mentioned above. They look, feel, and operate similar to the C# and Java classes so many enterprise developers have already embraced (yes, for better or worse).
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
Sure, classes are merely syntactic sugar. They don’t enable any new capabilities. And yes, classes also mask the power of prototypal inheritance. But this sugar does make it easy to encapsulate logic. Classes make it simple to declare static functions via a single keyword. There’s no need to learn a pattern. Which is good, because as I alluded to above, only your most dedicated client-side developers will bother learning alternative approaches like stampit or patterns like higher order functions.
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
Examples are increasingly written in ES6 using classes. Seeing familiar looking code when you Google is a major feature. It speeds reading and increases comprehension. Sure, we are free to use alternative approaches, but we do so at the risk of confusing fellow developers who are looking for code that matches the demos.
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
Yes, classes put developers in an object-oriented mindset which masks the true power of JavaScript, but I look forward to a future where JavaScript code bases aren’t composed of so many different styles. ES6 classes finally give us a clear, consistent, standardized pattern to follow. Clean code is about writing code for humans, so I favor the patterns that best convey my intent. While there are certainly risks of misuse, ES6 classes provide a practical, clear path for creating JavaScript applications in a consistent style.
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.
