I sometimes see difference between TypeScript's compiler and babel.

For example in this case TypeScript doesn't care so much about `defineProperty`. I guess the rules are not so strict, since it assumes that the rest of your code will be passed through TypeScript itself.

Anyway in both cases, I prefer TypeScript's way of enhancing the class inheritance in JavaScript by introducing private / readonly and many more.

https://www.typescriptlang.org/play/index.html#src=class%20D...

He's not telling people to not learn things or advocated changes to the language. Nor is he advocating the code you strawmanned above. He's saying he's found that `this` and `class` are best avoided. And I agree. I also agree that it's easier to test and reason about functional/procedural code or, more generally, code with fewer side effects and implicit state than OO code.

People usually share these thoughts, not out of desperation or ulterior motive, but because they've had experience with many paradigms and they've found these the most effective.

He's saying to prefer not using any version of classes, including the "hipster" alternatives to the class keyword, not just the class keyword itself. And I agree with him. But if I find the right use for classes, I enjoy using them. He was advocating for FP over OOP.

Code smell describes code which has incurred technical debts among other things. People do not have it.

The "latest language paradigms" in this case are JavaScript adopting a style of programming 40+ years old (Simula) -- despite its originating model being younger (self).

Adopting paradigms because they are "recent additions" to a language is cargo cultism.

Paradigms come with idioms that suit some problems better than others, and have all sorts of trade-offs and considerations.

Inheritance is now widely regarded as a design approach, overall, best avoided.

"easy to reason about" =/= hard to understand. The ease of reasoning about something is a feature of how complicated it makes it (partly, its incidental complexity). It's not to do with how dumb you are.

Inhertiance, for example, creates systems that are often needlessly hard to reason about.

We had a whole generation of class-heavy inheritance-ridden frameworks and applications. It's bad enough in static languages. In JS, it quickly becomes an unmaintainable pile of spaghetti.

Object literals with small doses (read: 1-2 levels at most) can be good. Going further risks multi-level breakage because properties are bound to get added/removed across the codebase over time due to the dynamic nature of JS.

> the ramifications of what they are doing

Which are? And why is "no new" a benefit?

IMO it's a good thing that you can write JS in the way you write other languages. It makes it a lot easier for developers to get going with it.

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

    Foo.prototype.constructor = Foo;

    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.

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

  function CatDog () {
     Cat.apply(this, arguments);
  }

  CatDog.prototype = Object.assign(Dog.prototype, Cat.prototype);

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.

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

    feedDog(dog.eat);

Totally agree, checkout this example:

> If you change/replace a method (on purpose or by accident) on the parent "class", the child "class" and/or instances will still be "affected"

I knew when reading this line exactly what the author was about to do to mislead the unsuspecting user. Directly edit the prototype and feign surprise. The prototype is representative of the class itself, basically a default of all properties for that class. The correct (and obvious) way to override a class method for only one member of the class is to assign a new function on the property directly, not into the prototype's version of the property. Class definitions being mutated in an application is extremely uncommon. This is like putting your hand on a hot stovetop and then complaining that you burnt yourself.