I think protected methods are just a bad idea in every case. They don't really offer protection (because a subclass can expose them) and they prevent other for

I think protected methods are just a bad idea in every case. They don't really offer protection (because a subclass can expose them) and they prevent other forms of composition even where they're more appropriate. If you're open to inheritance, you're necessarily open to composition - making that messy serves no purpose. As to this example: // Replace superclass method A.prototype.bar = function() { return "my own thing"; // obviously fine } This is NOT fine - it's really quite nasty. You're breaking encapsulation by affecting how the internals of B work - calls from B's code to bar() will now fail to work as expected. What you want is to use your bar to outside code, but not affect the encapsulation of the superclass. And note that none of this mitigates the pit-of-complexity that inheritance encourages as described in the post you replied to (i.e. bloated, hard-to-wrap API's). There are inheritance-like techniques that work better and don't have the downsides.