Go, Sarah!

Mistaking JS prototypes for classes indicates insufficient experience with both class-based and prototype-based OO languages. Even merely muddying the water with false-to-facts terminology is silliness (at best) of high order.

If one has a very deep background in both prototype- and class-based OO, e.g., Java, C++, I can maybe see pretending that JS is class-y. However, there are pitfalls from the nature of JS closures and weak datatypes that everybody in a shop using that approach should understand. There would need to be a very strong cultural motive to developing a front-end framework to support such an artifice and hard conventions - company policies - to enforce the appearance of class-iness (still no guarantee of safeguarding against obscure errors due to the fallacy).

The reward for treating JS as tho' it was class-based seems to me too little for the risk.

P.S. to Sandeep: you're an evil man to stir such controversies and tempt people publicly to debate these counter-intuitive and anti-dogmatic ideas...Thanks!

P.P.S. in the wee, small hours, related to arguments that JS CAN look class-y...

• JS CAN look Functional Programm-y too...I used it that way exclusively for about 5 years in a shop containing FPers; I still use it that way more than occasionally.

• Most OO languages can be used to code in entirely non-OO ways; the OOness of C++ and Java for instance is conventional, NOT required; you want REAL, no exceptions allowed OO, try Eiffel - no cheating.

• Try busting your preconceptions about closures at:

wiki.c2.com

(not necessarily right across-the-board but deliciously, bothersomely thought-provoking).

Settling questions can be unsettling. Some questions can't be permanently settled. The process of attempting to settle a question, whether possible or not, can be enlightening.

I don't really know the definition of "class based" well enough to say whether Javascript is class based.

So some random observations instead:

• It can be used in ways that that class based inheritance can be used.
• It can be used in different ways too, since prototype inheritance is more expressive.
• There not being a distinction between classes and instances might mean it isn't called a class.
• Individual instances not having the exact layout of the 'class' (prototype) also happens in other dynamic languages (so not inherent to the prototype system).
• It has data containers with methods and inheritance, which in my book is enough to be object oriented.
• I can imagine some people would want to stick to using it in a class-like way, since the extra power can lead to hard-to-follow code.

If I had a time machine, I would not go back to change the 'class' keyword, rather I would adapt Javascript to match the 'class' keyword better. Perhaps by replacing it with an entirely different language.

Imho, this is just about naming things. Some people call a concept Class, others call a similar concept Prototype. From a high enough view-point, they are the same. They are a blueprint to construct an object.

However, both are conceptually different. In JS, prototypes are run-time constructs, while classes are compile-time. They are not the same, if only for this argument (and there are more facts).

If you ask me, classes give the impression of a compile-time (write-time???) construct, however, under the hood, the JSVM treats them as prototype functions, which means a lot of confusion and many new JS devs who have trouble understanding in what ways "classes" can be manipulated at run-time.

JS is class-less. It has prototypes. Any good teacher or tutorial should explain the difference and naming conflict (as such). Intoducing the class-keyword was wrong, because it's something different.

// alternative how JS may have looked like, imho

// `name` will be a constructor parameter and be available as private field
// All inheritors have to declare it as well
const Animal = prototype(name) { // alternatively analog to `function`: prototype Animal(name) { //...
  constructor() {
    // define another private field:
    proto.myInternalCounter = 0;

    // `name` is a private field, make it publicly available:
    this.name = name;
  }
  eat() { /* ... */ }
};

const Mammal = prototype() {
  breed(otherMammal) { /* ... */ }
};

const Cat = prototype(name, furColor) inherits Animal mixes Mammal {
  // `furColor` is a private field, expose it as protected field, too:
  furColor: furColor;

  hunt() { /* ... */ }
  speak() { /* ... */ }
};

const myCat = new Cat('Mokka', 'brown');
const yourCat = new Cat('Snowflake', 'white');

myCat.hunt();
yourCat.eat();

console.log(myCat.name); // prints "Mokka"

const brood = myCat.breed(yourCat);

Yes, specially when function being the first-class citizen of the language. It would've been great if JS had never deviated towards Object Oriented Programming concepts and instead moved towards paradigms of Functional programming. Having mixed programming paradigms forces to compromise some principles against each other.