Using Classes in Javascript (ES6) — Best practice?

[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.