class-proto.js

/**
 * Creating objects with Classes
 * Versus objects with prototypes
 * Since JavaScript is not a Class-based language
 * what is happening behind the class syntax?
 */

let PersonC = class {
  constructor(nm, id) {
    this.name = nm;
    this.id = id;
  }
  getDetails() {
    return `${this.name} :: ${this.id}`;
  }
};
let bob = new PersonC("Bob", 123);
console.log(bob.getDetails(), bob.name);

let EmployeeC = class extends PersonC {
  // EmployeeC prototype links to PersonC prototype
  constructor(nm, id, salary) {
    super(nm, id);
    this.salary = salary;
  }
  employeeInfo() {
    //exist on the prototype of EmployeeC
    return `${this.name} :: ${this.id} :: ${this.salary}`;
  }
};
let noomi = new EmployeeC("Noomi", 456, 8500000);
console.log(noomi.employeeInfo());

///////////////////////////////////////////////

let PersonP = function(nm, id) {
  this.name = nm;
  this.id = id;
};
PersonP.prototype.getDetails = function() {
  return `${this.name} :: ${this.id}`;
};
let fred = new PersonP("Fred", 321);
console.log(fred.getDetails(), fred.name);

let EmployeeP = function(nm, id, salary) {
  PersonP.call(this, nm, id);
  this.salary = salary;
};
Object.setPrototypeOf(EmployeeP.prototype, PersonP.prototype); //extends NOTE: THIS LINE WAS CHANGED
EmployeeP.prototype.employeeInfo = function() {
  return `${this.name} :: ${this.id} :: ${this.salary}`;
};
let mary = new EmployeeP("Mary", 654, 65000);
console.log(mary.employeeInfo());

That was one of the most depressing things i've ever read. :D Hooks replace classes? "Over the last ~20 years this is the 3rd syntax I have seen emerge for creating objects and controlling the prototype chain. I would not be surprised to see another in the future." Well that's just nuts. To me, that says: haphazard and poorly-run language development project. It's hard enough to stay on top of web development with browser differences and languages changes. We know JS is famous for having rocky beginnings. Have they learned nothing? Active JS devs in fora are recommending that i just learn ES6, and not mess with older constructs. But you're saying the opposite. Maybe they're just being proselytizers, not realists.  Cheers!

You should absolutely learn the new syntax (ES6, 7, 8, Next). There are great improvements to the language that have been made over the last 5 years.

However, like you said, it had rocky beginnings and confusion over syntax due to pressures to make it look like and behave like Java and other OOP languages at the start. Most famous of these is the keyword new, which outside of a class-based language doesn't really make sense.

So, there have been many attempts to improve the syntax over the years when it comes to Object creation.

If the class syntax is the one that you learn first... great. go for it. But you can't stop there.

There have been three versions of the DOM too.

Everything (almost) is backwards compatible or, at least the old versions still run for the most part.

JS is a language out in the wild. Used on nearly every website built in the last 20+ years. When you have an interpreted scripting language with that level of penetration it can be a challenge. The competition between Netscape and Microsoft laid the rocky foundation for the language and features. It wasn't really until 2009 that things started to stabilize with ES5.

What has followed since was a series of faster smaller incremental improvements to the language, combined with the giant umbrella that is HTML5.

JS development for the web is not something for the faint of heart. But I prefer to think of it as exhilarating, not depressing.

There is ALWAYS something new to learn every day.

"Hooks replace classes?" - the hooks syntax meant that you didn't have to use the class syntax for every element or extend React.Component. You go simply create functions. So that is what people did.

thx for you detailed response.  Your description does make it sound like the syntax might be maybe stabilizing. No? i don't understand how the standards group is making sure in advance that their syntax is something that's going to be accepted by the dev community.  Of course there are always going to be some who don't like the changes, but if the community is basically split, or if there's a lot of hostility toward new syntax, that seems to say the standards group isn't doing their homework or including the dev community in the decision.  No? Personally, i don't find it exhilarating. I just want to get work done without going through hell. Just to learn it is made Is the nightmare scenario of bad features and conflicting browser platforms intended as a gate-keeping mechanism, to ensure only die-hard coders get into the club? A ploy to keep pay-rates inflated? That would be really self-centered-- web-development is the biggest coding need across society and needs stability, power, and consistency.  cheers!

Thank you for your video, I'm from Brazil, I wasn't finding a content like your, my doubts were solved.

Hi thank you so much for this video it helps all it
just I have one question what that easy way to do this class or prototype?

I interpret Classes as being a simplified version of what's going on behind the scenes using prototypes.

In addition to Object.setPrototypeOf(EmployeeP.prototype, PersonP.prototype);, don't we also need to set Object.setPrototypeOf(EmployeeP, PersonP); as well?

For the corresponding classes, I found that EmployeeC.__proto__ === PersonC evaluated to true. (Is that what enables a subclass to access static methods of a super class?) But EmployeeP.__proto__ === PersonP evaluates to false.

I got here from your YouTube videos. Thank you so much for posting those videos. I am trying to learn JS rigorously in the hope that I will be able to reason about programs. I often learn a topic from your videos first, before looking up books and documentation. (Otherwise at this point I'd get quite lost chasing references.) Your YouTube channel is such a valuable resource.

I interpret Classes as being a simplified version of what's going on behind the scenes using prototypes.

Classes are a wrapper for the prototypes in JS. It's just syntactic sugar.
Real classes use inheritance while prototypes use delegation.

Every function has a prototype object.
The prototype property is how you get to the prototype object from the function.
function Cat( ) { }
Cat.prototype
when you add a method to the prototype...
Cat.prototype.meow = function ( ) { }
when you create an instance of an object with the constructor function...
let bob = new Cat( );
the instance gets to use methods that are inside the prototype automatically
bob.meow( );
the Cat.prototype.meow method is delegated to bob.
If you need to access the prototype object directly from the instance we can use the proto property.
bob.proto.meow
Objects do not have a "prototype" property, they have a proto
If we want our object to be connected to a parent object for extending the delegation. Then we have another constructor function and it will have its own prototype.
function Animal( ){ }
Animal.prototype
For the delegation to be extended, we need the prototype chain to be established in a way that bob can call a method, say "drink"...
bob.drink( )
JavaScript looks inside the object bob for a method called drink. If not there it looks inside of Cat.prototype. If not there we want it to look inside of Animal.prototype for the method.
Cat.prototype needs to be connected to Animal.prototype. This is defining the prototype chain.
Object.setPrototypeOf( Cat.prototype, Animal.prototype )

By default, Cat.prototype and Animal.prototype will be connected to Object.prototype. By calling the setPrototypeOf method, we are changing the default for Cat.prototype to point to Animal.prototype instead of Object.prototype.
Animal.prototype still points to Object.prototype

I think we also need to add Object.setPrototypeOf(EmployeeP, PersonP) to address static class method prototype inheritance