4 ms·

What, that's all it does? Stop someone from accidentally not using the new keyword? I'm not dissing it, that's great it does this. But I'm a bit surprised (and

What, that's all it does? Stop someone from accidentally not using the new keyword? I'm not dissing it, that's great it does this. But I'm a bit surprised (and happy!) that this is all it does.

chatmasta 9y ago
Well, it also removes the need to tediously write prototype definitions...
- lucideer 9y ago
  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 9y ago
    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 9y ago
      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);
      - dmitriid 9y ago
        True, and that's what people use extensively. Class fields break `extends` though :)
      - 52-6F-62 9y ago
        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 https://github.com/andreypopp/autobind-decorator
couchand 9y ago
It's purely syntactic sugar. You can even get the new protection yourself: function Cat() { if (!(this instanceof Cat)) { throw new Error("please use new!"); } } or, if you want to be a bit nicer to your users: function Cat() { if (!(this instanceof Cat)) { return new Cat(); } }
- danlugo92 9y ago
  Seems like the 2nd option might prevent me from using Cat's as a mixin
  - danShumway 9y ago
    Both options will break mixins. function CatDog () { Cat.apply(this, arguments); } CatDog.prototype = Object.assign(Dog.prototype, Cat.prototype); In the above example, CatDog is not an instance of Cat, since it never actually inherits from the Cat prototype.
  - hajile 9y ago
    Mixins have terrible performance characteristics and lead to fragile code. While they were huge a few years ago, most new frameworks either avoid them or (in cases like React) chose to remove them for these reasons. In an existing codebase, that matters a lot. In newer codebases (or newer parts of existing ones) it shouldn't matter that much at all.
  - spiralx 9y ago
    Mixins in ES6 should be functions taking a class and returning another class that extends it: https://alligator.io/js/class-composition/ https://alligator.io/js/class-composition/
kowdermeister 9y ago
It's not really about the new keyword. It adds a lot more and simplifies a lot of things: - no more messing with .constructor, .prototype - calling parent object is super() easy :) - you can have static methods - no need to even type function for methods https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- grouchoboy 9y ago
  > - you can have static methods IMO create a class in Javascript and adding a static method is the opposite of simplify things. The simple way of doing it would be create a function in a module. For me the use of static methods in languages like Java is a workaround. But it Javascript that workarount is not necessary.
- Raphmedia 9y ago
  It doesn't simplifies anything, it simply uses keywords that are familiars to a lot of people. For someone that has learned JS as his/her first programming language, the new syntax is the one that feels confusing.
  - kowdermeister 9y ago
    As someone who learned JS as a first-ish language, I totally love how much simpler and cleaner the syntax is.
    - Raphmedia 9y ago
      Is it really simpler? Let's say you take two equal students with zero knowledge of programming and teach classical to one and prototypical to the other. Would the student learning classical inheritance grok it faster? I doubt it. I do agree that it is easier to understand the new syntax if you have experience with a language that use the same syntax. However, that's not learning anything new. It's simply using concepts that you already know.
      - 9y ago
Parsyval 9y ago
Well writing code is much simplier this, but devs that are familiar with 'classical' OOP languages will do a lot of mistakes because of what is in the article.
deleted 9y ago
[deleted]

What, that's all it does? Stop someone from accidentally not using the new keyword? I'm not dissing it, that's great it does this. But I'm a bit surprised (and happy!) that this is all it does.

chatmasta 9y ago

Well, it also removes the need to tediously write prototype definitions...

lucideer 9y ago
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 9y ago
  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 9y ago
    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);
    - dmitriid 9y ago
      True, and that's what people use extensively. Class fields break `extends` though :)
    - 52-6F-62 9y ago
      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 https://github.com/andreypopp/autobind-decorator

couchand 9y ago

It's purely syntactic sugar. You can even get the new protection yourself: function Cat() { if (!(this instanceof Cat)) { throw new Error("please use new!"); } } or, if you want to be a bit nicer to your users: function Cat() { if (!(this instanceof Cat)) { return new Cat(); } }

danlugo92 9y ago
Seems like the 2nd option might prevent me from using Cat's as a mixin
- danShumway 9y ago
  Both options will break mixins. function CatDog () { Cat.apply(this, arguments); } CatDog.prototype = Object.assign(Dog.prototype, Cat.prototype); In the above example, CatDog is not an instance of Cat, since it never actually inherits from the Cat prototype.
- hajile 9y ago
  Mixins have terrible performance characteristics and lead to fragile code. While they were huge a few years ago, most new frameworks either avoid them or (in cases like React) chose to remove them for these reasons. In an existing codebase, that matters a lot. In newer codebases (or newer parts of existing ones) it shouldn't matter that much at all.
- spiralx 9y ago
  Mixins in ES6 should be functions taking a class and returning another class that extends it: https://alligator.io/js/class-composition/ https://alligator.io/js/class-composition/

kowdermeister 9y ago

It's not really about the new keyword. It adds a lot more and simplifies a lot of things: - no more messing with .constructor, .prototype - calling parent object is super() easy :) - you can have static methods - no need to even type function for methods https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

grouchoboy 9y ago
> - you can have static methods IMO create a class in Javascript and adding a static method is the opposite of simplify things. The simple way of doing it would be create a function in a module. For me the use of static methods in languages like Java is a workaround. But it Javascript that workarount is not necessary.
Raphmedia 9y ago
It doesn't simplifies anything, it simply uses keywords that are familiars to a lot of people. For someone that has learned JS as his/her first programming language, the new syntax is the one that feels confusing.
- kowdermeister 9y ago
  As someone who learned JS as a first-ish language, I totally love how much simpler and cleaner the syntax is.
  - Raphmedia 9y ago
    Is it really simpler? Let's say you take two equal students with zero knowledge of programming and teach classical to one and prototypical to the other. Would the student learning classical inheritance grok it faster? I doubt it. I do agree that it is easier to understand the new syntax if you have experience with a language that use the same syntax. However, that's not learning anything new. It's simply using concepts that you already know.
    - 9y ago

Parsyval 9y ago

Well writing code is much simplier this, but devs that are familiar with 'classical' OOP languages will do a lot of mistakes because of what is in the article.

deleted 9y ago

[deleted]