1. As described this has serious issues when you reach depths greater than 1. This is why prototype has to use the hack of passing in a special super variable through the function arguments. This is also why in ExtJS, doing something that in any other language is a simple "super.method()" requires doing the following (from their own subclassing examples):

    Ext.ux.IconCombo = function(config) {
 
        // call parent constructor
        Ext.ux.IconCombo.superclass.constructor.call(this, config);
 
    };

Wow. Fantastic. Even if we ignore the Ext.ux, you can't tell me this isn't absolutely ridiculous. For starters, it requires access to the actual class object which is only slightly better than inlining the superclass' actual name yourself. It means if you ever change the class name there are additional points of failure (change it to IconComboBox, and now all your IconCombo.superclasses don't work if you happen to forget to modify them). Additionally, this is SO CONFUSING to beginners. Look, I can see that its "powerful" if thats what you want to call it, but people who want to write apps, and not sit around pontificating about languages have to understand so much to know what is happening in that one line of code. Beyond the verbosity, they need to get that they are taking someone else's function and then applying it to yourself while switching out the "this" (remember how I said this came into play with super calls). This is taking a problem that was hard to solve at the framework level and pushing it to the user.

2. For starters, you conveniently didn't mention how to handle private and protected member variables which is the actual interesting bit here. The goal is to not have people accidentally write into your internal data representations. This is modularization 101 and is really difficult to do with JS, since this._x = blah is accessible to EVERYONE. this._x is NOT protected in any way, every party has access to it and can change it. The "var fn" of course doesn't work with private member variables since you need one for each individual instance, you can of course do the closure trick inside your constructor:

function MyClass() { function() { var myVar = 5; this.getMyVar = function() { return myVar; } }

But this is recommended against by everyone since it 1. no longer has the benefit of modifying the prototype so its hard to inherit these methods without further trickery, and 2 is very very slow.

So no, this is not basic stuff. Not if you actually want to implement classical inheritance instead of just using names from classical inheritance and applying them to random orthogonal features.

3. Again, you run into the same super problems.

Look, I am willing to believe that people like prototypal inheritance, and I can respect the position that JS doesn't have classical inheritance because its not good or because you should use prototypal or whatever. But come on, lets not call a few hacks on top of it "classical inheritance".

Yes, I've seen Crockford's page. Its not particularly enlightening to this discussion. It presents several different forms of inherity-stuff, none of which are particularly classical in my opinion, which comes right back to the OP's original point: everyone ends up doing inheritance slightly differently and spends way too much time thinking about this problem. The fact that so much has been written on how to do inheritance in JS should be a red flag in and of itself. I will gladly take other language's "stricter less powerful" models because at least I can focus on programming and not the volumes and volumes that have been written on how to do something that should be as simple as inheriting methods.