“As much as I’d love our code to be fully compliant with the great programming practices of this world, I’d rather have it working — if possible before the heat death of the Universe.”
Classes are shortcuts to JS's prototypes and not really a new feature. The prototype is (roughly) a set of stuff that implicitly use the same this as a default context (that you can still override as usual).
When you declare value = () => {}, you don't write in the prototype, you merely create a property that's an arrow function, and arrow functions have as a default context the one of their parent object at declaration time.
If both your parent and child class use that syntax, you are not overriding it, you are overwriting it.
It's much easier to just use () => this.value() in your template and let the class syntax be what it is.
Plus, you get less memory used; methods in she prototype are shared between all instances, not class members declared through =.
My feeling is that it's strange the way classes have been implemented, which is, as you say, as kind of thin wrappers around functions. I don't understand the idea behind that approach. This properties transform thing now seems to be doubling down on that initial strangeness. I should probably do some additional reading to try to find out what the story is behind these decisions. Looking at it from the point of view of an "end user" programmer, it's hard for me to understand what the underlying logic is. If they want to implement the idea of a "class," why not do so with semantics that are more familiar? It would have the added benefit that the class properties syntax would presumably not be needed.
The story behind this is that the specification of the JavaScript language is closely tied to what browser vendors are willing to implement. For a feature to land in JavaScript, vendors must first provide native support for it (which is a long, error-prone and sometimes difficult process).
So the reasoning behind these thin wrappers and weird syntax is that they're easier and faster to implement.
That said, some things could have used more time and thought put into them (ex. auto-binding of class functions/methods), as once something has made it into the specification changing/removing it is sometimes impossible (vendors also strive for maximum backward-compatibility).
Classes are shortcuts to JS's prototypes and not really a new feature. The prototype is (roughly) a set of stuff that implicitly use the same
thisas a default context (that you can still override as usual).When you declare
value = () => {}, you don't write in the prototype, you merely create a property that's an arrow function, and arrow functions have as a default context the one of their parent object at declaration time.If both your parent and child class use that syntax, you are not overriding it, you are overwriting it.
It's much easier to just use
() => this.value()in your template and let the class syntax be what it is.Plus, you get less memory used; methods in she prototype are shared between all instances, not class members declared through
=.My feeling is that it's strange the way classes have been implemented, which is, as you say, as kind of thin wrappers around functions. I don't understand the idea behind that approach. This properties transform thing now seems to be doubling down on that initial strangeness. I should probably do some additional reading to try to find out what the story is behind these decisions. Looking at it from the point of view of an "end user" programmer, it's hard for me to understand what the underlying logic is. If they want to implement the idea of a "class," why not do so with semantics that are more familiar? It would have the added benefit that the class properties syntax would presumably not be needed.
The story behind this is that the specification of the JavaScript language is closely tied to what browser vendors are willing to implement. For a feature to land in JavaScript, vendors must first provide native support for it (which is a long, error-prone and sometimes difficult process).
So the reasoning behind these thin wrappers and weird syntax is that they're easier and faster to implement.
That said, some things could have used more time and thought put into them (ex. auto-binding of class functions/methods), as once something has made it into the specification changing/removing it is sometimes impossible (vendors also strive for maximum backward-compatibility).
Thank you, that’s a really helpful perspective!