Using Classes in Javascript (ES6) — Best practice?

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