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/Refe...

You should never be using `.constructor` anyway because it isn't reliable because a very common pattern replaces the `.prototype` with a new object who's `.constructor` is `Object`

    var Foo = function () {};
    Foo.prototype = {
      bar() { return 'bar'; }
    };
    var f = new Foo();
    f.constructor === Object;

When you use `class` you are still messing with `.prototype`. The danger is that programmers new to JS don't understand that they are and don't understand why that matters.

Calling `super` is very anti-pattern in JS. Unlike classic OOP, parents are not static. Lots of very common things can rip that rug out from under you by modifying the parent in many different ways (createProperty, Symbols, proxies/reflection, etc).

Static methods do indeed exist without classes.

    class Foo {
      static bar() { return 'bar'; }
    }

    //is identical to

    function Foo() {}
    Foo.bar = function() { return 'bar'; }

If you use `Object.create()` and ES6 object literal syntax you don't have to type `function` either. You get the added bonus of being easily able to wrap it in a normal function that avoids constructor weirdness

    var someProto = {
      bar() { return 'bar'; }
    }
    var myInst = Object.create(someProto);

To be absolutely fair, the pattern at the top is buggy in that you're supposed to also set

    Foo.prototype.constructor = Foo;

...after replacing the prototype object that way. MDN (for example) covers this in a few pages, including:

https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Ob...

That said, it's a pretty common bug, particularly with stuff like:

    Foo.prototype = Object.create(FooParent.prototype) // Crockford-style inheritance
    console.log(Foo.prototype.constructor.name) // "FooParent"

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

I'm actually a fan of the class syntax, and use it regularly.

>no need to even type function for methods

However, to be fair, you can do this with object method shorthand now:

    const deepThought = {
              theAnswer: 42,
              tellTheAnswer() {
                  return `The answer to life, the universe, and everything is ${this.theAnswer}`;
              },
          };

    deepThought.tellTheAnswer(); // => 'The answer to life, the universe, and everything is 42.'

Which is also quite elegant. I think they both have their places depending on the program. I think it depends on readability needs at the time, and whether an instance is better than just a container in that circumstance.

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.

As someone who learned JS as a first-ish language, I totally love how much simpler and cleaner the syntax is.

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.

Prototypical inheritance may seem simpler at first glance. But understanding how to use it correctly can be extremely difficult, even for experienced JavaScript developers, mostly because there are so many different ways to achieve almost the same thing, but with subtle differences. For example, you can reuse a single object instance as a prototype for multiple others. Or you can create a new instance of the prototype for each instance of the child. The two are similar, but affect e.g. whether or not properties in the prototype are shared or unique.

In the past I've eventually resorted to copy and paste the same template every time I wanted to use inheritance with prototypes. With classes, I never have to think about these problems anymore. There is one way to define a class, and it always works like I expect it to.

But that's the metric everyone uses to gauge a language.

Look at all the complaining about Lisp and Rust syntax which boils down to "ugh, this is unfamiliar."

But to answer your question, I think they are both within a pebble toss distance of each other. But still much harder than other languages due to `this`. `class` just unifies some patterns people were doing like inheritance.

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();
      }
    }

Seems like the 2nd option might prevent me from using Cat's as a mixin

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.

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.

Mixins in ES6 should be functions taking a class and returning another class that extends it:

https://alligator.io/js/class-composition/

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

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.

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)

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);

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

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

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.