[lucideer]

Exactly. It's surprisingly well thought through. Literally the best of both worlds: it's not some entirely separate "new way" that's incompatible with the old way and adds significant implementation baggage, but still makes the most common in-the-wild use of prototypes shorter, while also being intuitive for non-Javascripters, and still allowing experienced old-school Javascripters access to the same prototype chain they're used to.

[dmitriid]

They are well thought through until you add class fields into the mix (already at stage three) and the actual real world usage (where you have to do this.method.bind(this) for every methods used in per-instance callbacks)

[lucideer]

Agree on class fields but there's high demand. I haven't examined the exact detail but it seems hard to please both sides here. Not sure what the best way forward is.

On .bind(this), that's exactly what I meant by keeping the old system. "Fixing" that magically would have required underlying changes. That said, since you brought up class fields and bind in the same post, there's always:

    class Dog {
      bark() { console.log('Bark!'); }
      eat = (food) => console.log('Munch');
    }

    feedDog(dog.eat);

[52-6F-62]

My favourite solution so far is the @autobind decorator. It's far from native yet, though. And of course, enters the newer decorators feature which drifts ever closer to Java-like syntax to some peoples' chagrin.

https://github.com/andreypopp/autobind-decorator

[dmitriid]

True, and that's what people use extensively. Class fields break `extends` though :)