Discussion on: The true prototypial nature beneath "JavaScript classes"

[John Peters]

This article and others like it in the JavaScript community remind me of how Java and C# people rejected JavaScript. Some rejected it for 10 years or more, until the ubiquitous nature of JavaScript forced everyone to learn it. Today's JavaScript is radically different from the first release. So many improvements have been made that almost everyone likes it now.

The JavaScript Prototype's Compositional Signature

This is the signature of a compositional pattern. It shows us there are three composites, a Person, a Prototype and a property. Composition is always good. But this particular code is busy, a full 32 chars. just to get to what the function does. I don't and never have liked the readability factor here.

Person.prototype.name = function() { return firstName + ' ' + lastName }
Person.prototype.greet = function() { ... }
Person.prototype.age = function() { ... }

Typescript Vaporizes Prototype Syntax!

... by automatically compiling all properties to prototypes. We never need to write the prototype syntax again!

Everything else in a Typescript compile are functions, including the "Class" construct if we target ESM5.

This means : free getter, setters, no use of Object.create, no diving to the obscured prototype layer, fantastic readability. If we don't like the 'new' or 'constructor' syntax, then we just skip them like this:

class Person {
  //Typescript makes these props prototypes
  firstName;
  lastName;
  birthYear;
  type;
  // Optional can be called
 //  But doesn't have to be implemented (it is over-rideable)
  fullName?() {
    return `${this.firstName} ${this.lastName}`;
  }
}

// Skip the new and constructor stuff
function UsingThePersonClass() {
  // Using Javascript object notation 
  // With Typescript Typing annotation
  // Automatic auto-completion of props. as we type 
  let obj: Person = {
    firstName: "first",
    lastName: "last",
    birthYear: 1976,
    type: "M",
  };
  // Return default result of fullName()
  return obj.fullName();
}

No need for interface definitions because a class is an interface with the added ability to initialize values! Simple, terse, clean and easy. Super readable!

In all honesty, the JavaScript Community's resistance to new approved standards within their own language is understandable. They are blinded to their first love as it was. The only problem now is that the first love is no longer there.

[calvintwr]

Nicely put, I can't agree with you more. The greatest relief in fact, if any, about the ES6 classes syntax, or the TypeScript syntax, is thankfully -- as you rightfully pointed out -- that you can still write simply and readably. Albeit it also can be turned into something really hardcore that looks half-intellectual and half-mangled. I really don't like the people who write such codes thinking that it's your fault you won't understand it.

So I guess I had two main points which is that readability must always be preserved. And yes related to the first love, still can't let go 😂 -- that it should have been proto instead of class, and create instead of new.

Wonderful comment, thanks.

[calvintwr]

Btw, your code gives the error of Cannot invoke an object which is possibly 'undefined'. on obj.fullName(). Any idea how to fix that?

Also, why do you need to wrap it in #UsingThePersonClass().

[John Peters]

The wrapping was just to show how to use the Person class.