There's a whole depth of abstractions that people imply when they talk about OOP in JavaScript. In my mind they go something like this. 1) Using object lit

There's a whole depth of abstractions that people imply when they talk about OOP in JavaScript. In my mind they go something like this. 1) Using object literals for values. 2) Using object literals with functions. 3) Using object literals with functions and calling them in contexts (`this`, `bind`, `apply`). 4) Using the `new` keyword. 5) Designing objects with inheritance hierarchies or prototype chains. 6) Designing mutable and stateful objects with indefinite life spans. I don't understand the arguments that classical-ish inheritance in JS is bad while prototypical inheritance is somehow better. I've worked in codebases that liberally extend objects into different types of objects with long prototype chains, and IMHO they suffered from the same problems that people complain about in classical inheritance: tight coupling, premature/wrong abstractions, gradual violations of open/closed, etc. Personally, I go through 1-4 liberally and 5 and 6 conservatively. IMHO, complaints about inheritance mechanisms seem to have something in common with the people who talk about the special needs of "large-scale applications". Why not just make smaller apps, or make smaller things that compose with less knowledge of where they are? NB: It's entirely possible that I haven't run into the kind of complex requirements where liberal inheritance is a good fit. I'd be interested in hearing stories about when that worked out well.