Is ''Class'' in ES6 the New ''Bad'' Part?
Is ''Class'' in ES6 the New ''Bad'' Part?
So, class in ES6... some like it, others don't. Let's go over some of the pros and cons, and you can make up your own opinion about it.
Join the DZone community and get the full member experience.
Join For FreeDeploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.
Yesterday, I wrote a blog 5 JavaScript "Bad" Parts That Are Fixed In ES6 and mentioned “Class” as one of the fixes. Since then, I’ve received a ton of responses where many thought that the “Class”-syntax in ES6 has gotten better and more useful. However, others indicated that there was no need for the “Class” keyword because JS doesn’t have the concept of “Class” (i.e blueprint). In fact, their argument is that it may make things worse, because ES6's official “Class” is just syntactic sugar and not technically and conceptually accurate (i.e. it’s false advertisement or cause for more confusion).
Let’s see the arguments from both sides for a better understanding.
Argument: Class In ES6—The "Good" Part
The first thing people learn when they study OO language is the concept of Class and how inheritance works and so on. In JS you could simulate a “Class” and do OO programming from the beginning. However, there was no “Class” keyword and the code to set it up, create sub classes, and call parent’s functions was weird and confusing.
Also, most JS folks just want to do basic OO stuff and move on. But, the current syntax throws them off.
Further, this is an optional way of creating Objects. It doesn’t prevent people from creating objects using other techniques like “function factories,” “Object literal,” and so on.
So making the syntax look better and similar to other OO languages, while still keeping the “prototype” inheritance goodness is a good thing. People can use other ways if they don’t want to use “Class” to create Objects.
Argument: Class In ES6—The New "Bad" Part
1. Conceptually There Is No Class in JavaScript
Objects are created without Classes! The best way to explain this is to use the real-world analogy of “Living things” (like humans) versus “Nonliving things” (like cars, furniture, etc.).
The below picture depicts how object creation differs in Java from that of JavaScript.
Objects in Java World vs. JavaScript World
As you can imagine, in JS, there is no overhead or constraints of needing a Class to use objects. Further “prototype”-chain based inheritance can wire up any object to any other object that may not be related (IS-A relationship). So it’s very flexible compared to Classes.
2. Bad for Functional Programming
In JS, functions are first-class citizens. Functional programming is all about using functions to their fullest extent. There is a notion called: “Favor Composition over Inheritance” and here we are going in the opposite direction because “Class” notation favors “Inheritance over Composition”.
Summary
It's a good thing because:
- Class is something everyone learns and making the syntax better is a good thing.
- It’s an optional feature and there are other ways to create objects like factory functions.
- Using it for limited purposes is fine.
It's a bad thing because:
- The concept of “Class” doesn’t exist in JavaScript.
- Concept of classes makes things brittle. Prototypes are better and very flexible.
- It guides people away from the goodness and power of functional programming.
So, where do you stand? Is “Class” in ES6 the new “bad” part?
That’s it!
Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.
Like This Article? Read More From DZone
Published at DZone with permission of Raja Rao , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}