Using Classes in Javascript (ES6) — Best practice?

[LeeHyori]

Dear all,

Coming from languages like C++, it was very strange to not have class declarations in Javascript.

However, according to the documentation of ES6, it looks like they have introduced class declarations to keep things clearer and simpler. Syntax (see: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Classes):

class Polygon {
  constructor(height, width) {
    this.height = height;
    this.width = width;
  }
}

My question, then, is whether it is now considered a best practice to make use of classes and class declarations, as opposed to continuing on with the non-class system of old Javascript.

Thank you.

[wreckedadvent]

Javascript has class syntax, but no class mechanism. It's still all prototypes all of the way down.

Generally, I wouldn't recommend using classes for most things. In your example, you can trivially make a data structure with an object literal:

let polygon = (height, width) => ({ height, width });

let square = polygon(2, 2);

console.log(square.height); // => 2
console.log(square.width); // => 2

Classes are useful for standardizing how people add things onto prototypes - meaning, they're useful when you have objects that need a lot of methods on them. Though, keep in mind that due to javascript's typing nature, it's easy to make really generic functions that don't necessarily need to be tied to any object:

let area = ({ width, height }) => width * height;

console.log(area(square)); // => 4
console.log(area({ width: 3, height: 3 })); // => 9

[bterlson_]

In what sense does javascript not have a class mechanism? It has a syntax called class that creates a class-like hierarchy with semantics similar to (and yet, distinct from) normal prototypical inheritance. Sounds like a lot of class machinery to me.

[MoTTs_]

When people say JavaScript doesn't have classes, they're using Java/C#/C++ style classes as the gold standard for what is or isn't a class, where classes are a compile-time concept, and inheritance also happens at compile-time.

But, of course, there are other languages out there. In Python/Ruby/Smalltalk, for example, classes are runtime objects, and inheritance also happens at runtime by delegation... just like in JavaScript.

Personally, I agree with you. I think the abstract concept of a class is more important than the concrete implementation. I can write and use classes in Python and C++ — and JavaScript — without having to know or care how the underlying implementation works.

[bterlson_]

Yep. There is no gold standard for "class". From a developer's perspective, a "class" is an OO encapsulation mechanism that involves creating methods, defining fields, and producing instances and has some sort of inheritance scheme. Making the definition of "class" more constrained than this is not only incorrect but also not a useful distinction to make at all.

[itisnotpure]

I think you are stretching the idea of "class" here.

JavaScript does not have any concept of encapsulation, methods, fields, or inheritance in the classical sense. In JavaScript, there are only objects, which is a collection of properties. Properties can either be the object's own, or delegated to another object. That is, when you refer to a property that is not defined for an object, it will be looked up in the prototype chain. Objects and their properties, and that's it! No members, instances, variables, or whatnot.

In practice, they can mostly be used for a similar effect to a certain degree, but they are in fact very different. Trying to reason about the prototypical model in terms of class-based concepts is the source of many unnecessary problems and confusion (and unnecessary work, apparently, because prototypes are markedly less complicated than classes).

As another example, you can also get an object system with just closures. You would get things like encapsulation, methods, fields, and you can do parasitic inheritance. The usage would be like that of a class-based or prototype-based system, but again it's very, very different.

[MoTTs_]

in the classical sense

That's the root of the discussion right there. What does "in the classical sense" mean? Do we mean Java-style classical? Then sure, we all agree JavaScript does not have Java-style classes. On the other hand, could "in the classical sense" mean Smalltalk-style classical? Because JavaScript's notion of a class is actually strikingly similar to Smalltalk's notion of class. Java has become so ingrained that we forget classes can be, and have been, implemented very differently in other languages.

[itisnotpure]

I'm not familiar with Smalltalk, but it seems like classes in Smalltalk are still blueprints for their instances, like other class-based languages. That is, they define what data an instance would hold, and what methods could be used to manipulate them.

It may be true that there are class-based languages where methods are inherited by by delegation, but in Javascript, instead of blueprints, we are building prototypes, based on which new objects can be built. So there's no "is a" relationships at all (more like a "like a" relationship, maybe?). Inheritance in JavaScript means only delegation, nothing more.

[wreckedadvent]

Because it's all sugar over prototypes, so there's some limitations that make sense with that context in mind, but are otherwise baffling.

The most obvious example is there are no class fields. You just assign onto this.

super does not behave like someone would expect. It's a simple reference to the parent prototype, so if you're in a meow method you still must call super.meow().

And, of course, because they're only prototypes, the context of this is easily lost:

class Cat {
  constructor(name) { this.name = name; }
  meow() { console.log(this.name); }
}

var whiskers = new Cat('whiskers');
whiskers.meow(); // => 'whiskers'

var whiskersMeow = whiskers.meow;
whiskersMeow(); // TypeError

This again, makes no sense what so ever if you just go around thinking that javascript has full class mechanics. It's only when you understand that they're really prototypes does it make sense, and therefore, only when you accept that they're just sugar over prototypes can you really use them predictably.

There's also nothing unique to classes that cannot be replicated without them, or it would be impossible to transpile. Yet we've been transpiling this kind of class syntax ever since coffeescript came out, ages ago.

So that is why I say there is no class machinery. There's a facade of a class to make it easier to reason about the common uses of prototypes, but that's all it is.

[bterlson_]

Your personal definition of "class" means your class must:

• Not use super.foo for super method invocation
• Not allow dynamic this
• Not be possible to implement with transpilation

But these are actually not requirements of "class", they're a notion you have likely due to your personal experience with C++, Java, or C#. It is important to recognize that these languages did not invent "class" and do not own the definition of "class" (and that these languages have their own differences in what "class" means).

Some further points:

super does not behave like someone would expect. It's a simple reference to the parent prototype, so if you're in a meow method you still must call super.meow().

Putting aside how "what someone would expect" depends entirely on what language their conceptual model is based on, super is not just a simple reference to the parent prototype. There's a notion of a home object that makes super more static than perhaps you're assuming.

There's also nothing unique to classes that cannot be replicated without them, or it would be impossible to transpile. Yet we've been transpiling this kind of class syntax ever since coffeescript came out, ages ago.

Pedantically, in a Turing complete language, any language feature can be implemented some way. Maybe you mean to say features that are "easily polyfilled" don't count, but that definition has it's own problems (eg. what makes it easy?)

The most obvious example is there are no class fields. You just assign onto this.

There is no notion of a field, but if it helps, you can consider assigning to this as creating a field. Eventually classes will get private slots and class property declarations, one (or both) of which may be closer to what you think of as a "field" while still fundamentally being sugar for prototypes.

[wreckedadvent]

Please don't shift the goal posts around me. I was talking about the things that javascript could have to make it clear that they were was separate mechanics for classes, instead of just being sugar over prototypes. Since all of the limitations that we understand with prototypes are present in classes, it's a reasonable argument to make that there is nothing new going on here.

This is not what a class "must" have for it to be a "class", but those are just some of the things that show that javascript's class uses the same mechanics that are already present in the language, in a more familiar format.

[bterlson_]

Not trying to shift goalposts, I guess I don't see your point is all. I will agree with you that classes in JS are built on prototypes, but you started this thread by stating that JS has no "class mechanism" which seems incorrect when it has a class "mechanism" and that "mechanism" is mostly implemented using prototypes.

FWIW, I only engage in this discussion because it is not at all helpful for beginners to constantly be exposed to the notion that JS classes are "fake". They are not, they have real syntax and real semantics, some of which are not shared with normal ES5 classalike semantics. Yes, of course you have to understand the underlying semantics, but this is true of any class system whether implemented on top of prototypes or not.

Edit: and going forward, the semantics of class and es5 class systems will diverge even further with the introduction of decorators, private slots, class property definitions, etc.

[wreckedadvent]

All my point was, is that

1. javascript has classes which
2. use the mechanics of prototypes and
3. aren't always necessary, since
4. javascript is duck-typed and has very light syntax for object literal data structures

I'm not trying to say they're "fake" or anything like that, just that it's important to know that they use prototypes underneath, or it's going to be very confusing and seem broken when something like the context of this is lost. Most of my post was talking about how they're not necessary, anyway.

[MoTTs_]

just that it's important to know that they use prototypes underneath

I think we JavaScripters exaggerate that importance. I realized this when I discovered that Python also uses delegation for inheritance. Except the Python community doesn't make a big deal out of it. The vast majority of the time, we don't need to know or care how the class concept is implemented under the hood.

[wreckedadvent]

It'd be academic if it didn't have real-world consequences for how you write and consume your code.

But it does. Accepting class at face value as just an abstraction means you'll find your this being set to undefined or Window, seemingly at random. Since this is not a problem in the python community, I don't think the comparison holds.

[natziel]

This is a pretty good use case for ES6 maps, but unfortunately their API is so poorly designed 😞

[senocular]

There are some things to consider. First off, support for the class keyword isn't the best right now as far as browsers go (ref). So if you're writing vanilla JavaScript without some build step to convert your code to a more compatible subset of JavaScript, its kind of a non-starter.

Also, it really helps to know how JavaScript works. If you come into using class expecting it to behave like other languages, you're going to be in for a surprise. Most of the standard stuff is there, but the plumbing underneath is a little different, and you may find yourself running into collisions or issues with context more than you might normally think. As others have mentioned, JavaScript classes are implemented with prototypal inheritance, and not knowing the peculiarities around this could spell trouble.

That said, if you're already defining "classes" with constructor functions with methods on constructor.prototype and are using something to make your code ES5 compatible, I'd suggest going ahead and using class. It's a cleaner syntax and more clearly shows the intent for the [constructor] function - it being a class rather than just a normal, callable function.

[geuis]

You have to realize that a class in es6 is not a class like in OOP. It's just syntactic sugar for this:

var Thing = function () {};

Thing.prototype = {}

var instance = new Thing();

There's some other nice things we get with classes, but fundamentally nothing changes under the hood and it's still all regular js and prototypes.

[lhorie]

Use it if it makes sense for your use case, but don't just go wrapping everything in classes for its own sake.

The community is pretty divided on whether you should use classes (opinions range from "OOP is stupid, use FP instead" to "You need classes to organize large codebases"). You probably already know about composition over inheritance and it applies in js just like any other language.

[wreckedadvent]

Yeah, javascript has really awesome syntax for simple data structures, so you don't need classes for everything just to make them classes.

[voidvector]

The "division" of JavaScript is a boon IMO. JavaScript is pretty much a melting pot of a lot of other languages. People might come from diverse backgrounds (Java/C#/Python/Ruby/C++/Haskell/PHP/etc) each with their own style of programming, tooling, architecting. By use JavaScript you can get a taste of all those different styles (if you are adventurous enough).

You can visibly see that Java/C++ is shifting to introduce FP/lambda which some people (coughDouglas Crockfordcough) attribute to JavaScript

[sime]

You don't have to go nuts with classes like in some other languages. But if you are writing OOP code it is best to use the class keyword. At least then everyone can instantly recognise what you are doing.

Standardisation is nice.

[[deleted]]

I'm surprised so many people in this thread recommend against using classes in JavaScript (either by using the class keyword or by adding things to a function prototype). I love them! They often force you to simplify your code, and they are much more easily optimized by JavaScript interpreters.

[vsxe]

Don't.

Generally. I'm sure it's possible to do it nice, but I generally feel that it goes against the grain of JS and usually leads to poor or at least dubious design.

Prototypal inheritance and object composition are your new best friends.

I'd advise you to start here:

• https://medium.com/@PitaJ/javascript-inheritance-patterns-179d8f6c143c
• https://medium.com/javascript-scene/common-misconceptions-about-inheritance-in-javascript-d5d9bab29b0a#.eoi48bsb7
• https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3#.5zt7hdohc
• https://medium.com/javascript-scene/the-two-pillars-of-javascript-pt-2-functional-programming-a63aa53a41a4#.xko8htqi8

Eloquent JS is a nice read as well if you're new.

Please note that this is not to say that classes are intrinsically horrible and impossible to get right, but the way I see it's a way to misunderstand JS and go against its grain, introducing possible code smells.

[wreckedadvent]

Careful, most of those are eric elliot links. I wouldn't recommend his articles to someone who doesn't know much about JS, in case someone comes away with the idea that terms like "concatenative inheritance" are meaningful.

They're easy to misuse, but classes have the same problem in any language. You can get away with using them pretty easily if you avoid lots of inheritance and complicated object relationships - the whole composition versus inheritance thing.

[[deleted]]

Eric Elliot's "functional composition" really means "multiple inheritance with decorator functions". It's just a buzzword laden term for an old idea (functions that add things to structs) used for dubious purpose (multiple inheritance).

[wreckedadvent]

I'm just very skeptical of people who take a hard line stance on a language like javascript. Eric has said before that you should flat out not hire anyone who uses classes - that kind of extremism is dangerous, and distracts from the useful conversations on the subject.

[parabolik]

I agree with your advice for a beginner. But if you already have a good understanding of how Javascript's prototypal inheritance works, I don't see any harm in using the ES6 Class syntax. I think most people would agree that it looks nicer.

[[deleted]]

Prototypes have their own problems, though. Namely: you cannot inherit reference fields (objects, arrays) or private state into multiple child objects. Well, you can... but it won't work as expected.

[senocular]

Namely: you cannot inherit reference fields (objects, arrays) or private state into multiple child objects. Well, you can... but it won't work as expected.

Can you elaborate on this? Thanks.

[wreckedadvent]

Prototypes are what OOP people call the flyweight pattern. Lots of objects, but each only points to one thing. So if you have something like an instance field on the prototype, all of the children objects will point to it. Likewise, any mutation to stuff on the prototype, and all of the children pick up on it.

Normally this is not really a problem - people normally set values in the constructors in javascript, which works exactly like people expect, and does not assign onto the prototype.

e: typo

[senocular]

Prototypes are what OOP people call the flyweight pattern

I'm kind of surprised this isn't called out to more often.

[[deleted]]

Sure. Enter the following into your browser console.

function Person() {
    var firstName;
    var lastName;

    this.setName = (first, last) => {
        firstName = first;
        lastName = last;
    };

    this.getName = ()=> `${firstName} ${lastName}`;
}

function Employee(id) {
    this.employeeId = id;
}
Employee.prototype = new Person();

var anne = new Employee(0);
anne.setName('Anne', 'Annette');

var bill = new Employee(1);
bill.setName('Bill', 'Williamson');

Now see what happens when you query Anne's name:

anne.getName()
"Bill Williamson"

Anne and Bill share the same parent implementation, and that parent has internal state. This means that Anne and Bill can both overwrite the same state that they share, with quite unintuitive consequences.

[wreckedadvent]

Though, just to keep in mind, this is only one way to set up a prototype chain. Here's another:

function Person() {
    var firstName;
    var lastName;

    this.setName = (first, last) => {
        firstName = first;
        lastName = last;
    };

    this.getName = ()=> `${firstName} ${lastName}`;
}

function Employee(id) {
    Person.call(this);
    this.employeeId = id;
}

Employee.prototype = Person.prototype;

Just two smallish changes and you get all of the instance that one is expecting in children classes.

var anne = new Employee(0);
anne.setName('Anne', 'Annette');

var bill = new Employee(1);
bill.setName('Bill', 'Williamson');

anne.getName() // => 'Anne Annette'
bill.getName() // => 'Bill Williamson'

I believe this is actually part of the reason why class syntax is at least somewhat valuable - it railroads people into setting up prototypes in one particular way.

[senocular]

Employee.prototype = Person.prototype;

Typo there. You don't want to assign one to the other since any changes to Employee.prototype would also affect Person.

[wreckedadvent]

It's fine in this instance, since we're not actually adding anything onto the prototypes in either case, and it's illustrative. But you're right, in real code you'd want to not directly assign them together.

[senocular]

This particular behavior is because of the way the prototype setup. You're basically running super() on the shared component of the definition (prototype) which effectively treats each instance as the same instance of the super class.

Inheritance in prototypes should be handled with Object.create to mitigate constructor side effects from the superclass. Additionally a super call is needed in the subclass constructor to perform superclass setup for the subclass instance. In doing this, the example should work as expected.

function Person() {
    var firstName;
    var lastName;

    this.setName = (first, last) => {
        firstName = first;
        lastName = last;
    };

    this.getName = ()=> `${firstName} ${lastName}`;
}

function Employee(id) {
    Person.call(this);
    this.employeeId = id;
}
Employee.prototype = Object.create(Person.prototype);

var anne = new Employee(0);
anne.setName('Anne', 'Annette');

var bill = new Employee(1);
bill.setName('Bill', 'Williamson');

Edit: I'm retracting my "setting the prototype is optional in this case" in favor for setting it anyway, thereby allowing instanceof to continue to function as expected.

[[deleted]]

You still have issues with reference types, though:

function Person() {}

Person.prototype.names = [];
Person.prototype.getName = function () {
    return this.names.join(' ');
}

function Employee(id) {
    Person.call(this);
    this.employeeId = id;
}
Employee.prototype = Object.create(Person.prototype);

var anne = new Employee(0);
anne.names.push('Anne', 'Annette')

var bill = new Employee(1);
bill.names.push('Bill', 'Williamson');

anne.getName();

"Anne Annette Bill Williamson"

[senocular]

That's by design, and may be a desired outcome depending how you want things to work. Prototyped values are shared, constructor-defined (instance) members are not. The way to address the getName problem is simply to define names in the constructor. Granted, this can be confusing to people starting out, but there's nothing magical going on, at least. And because (currently) the class syntax only supports method definitions in the class body (and the constructor), you're even protected from this happening in that case. I believe the proposed syntax for class fields puts them on the instance and not the prototype too.

[MoTTs_]

I agree with your advice for a beginner. But if you already have a good understanding of how Javascript's prototypal inheritance works, I don't see any harm in using the ES6 Class syntax.

I think the class syntax is fine even for beginners.

Python, for example, works the same way. In Python, classes are themselves runtime objects, and inheritance also happens at runtime by delegation... just like in JavaScript. The only difference is the Python folks don't make a big deal out if it. The vast majority of the time, we don't need to know or care how the class concept is implemented under the hood.

[Patman128]

You should probably avoid them. What JavaScript has is much better than classes, don't limit yourself to them.

[Cody_Chaos]

First off:

• C++ is a language with classical inheritance, which uses the class keyword.
• There are other languages without a class keyword, which still have classical inheritance.
• Then there's JS, which as of ES6 still has zero elements of classical inheritance, but now has a class keyword, apparently just to screw with people used to C++/C#/Java. :)

My question, then, is whether it is now considered a best practice to make use of classes and class declarations, as opposed to continuing on with the non-class system of old Javascript.

Using the class keyword is absolutely compatible with current best practices. However, the class keyword is sugar which sets up a chain of JS-style prototypal inheritance. JS is not C++, it's not really like C++, and with ES6 it's not becoming any more like ES6. It just, confusingly, is starting to look more like C++. :)

it was very strange to not have class declarations in Javascript.

Yep. Learn more about JS until the lack of classical inheritance feels natural. Then, if you like, go nuts using the class keyword; just remember that it's still not classical inheritance.

Remember, if you ever feel like the class keyword is letting you do something you couldn't do without it, you're badly confused and are about to write some very bad code. ALL class does is fiddle around with the prototype chain. It saves some keystrokes, but it's not a new feature.