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