I do still consider implementation inheritance to be useful. But it's certainly used poorly in a lot of circumstances (along with MOST of OO design, including most of Java), and it may encourage bad habits. And I agree that composition is often a better answer. Depends on what you're doing.
Aside: Do JS linters actually enforce a no-semicolon policy in real projects?! I started using jshint and jscs recently in part to enforce the use of semicolons (on the advice of "JavaScript: The Good Parts"). I see that jscs has a "disallowSemicolons" rule, but I didn't know stupidity went to such depths as to actually USE that rule...I thought it was there for completeness...
Yes, they do. See https://github.com/feross/standard/ as a preconfigured example.
> (on the advice of "JavaScript: The Good Parts")
To paraphrase The Dude: yeah, well, you know, that's just, like, Crockford's opinion, man; whether you want to use them or not, there's tooling to support you either way.
1) I agree that the author sounds like a lot of developers who have a "What am I going to do without the exact class semantics I'm used to?" moment when they get to JS, and rather than learn to answer that question, they either decide that it's an inherent black mark on the language or go on a long quest trying to get something more like the semantics of another language in JS (often frustrating because it's almost possible).
2) More importantly, though... implementation inheritance itself is something a lot of thoughtful developers look on with a skeptical eye. Hence Gosling's comment about "I'd leave out classes" if he were starting over with Java, or Golang's interfaces. I wouldn't go so far as to call it "pants-on-head stupid" (I'll reserve contempt on that level for JS linters that enforce a no-semicolon policy), because it can be a nice mechanism for re-use, but it has its problems (fragile base class) and really only ever fits ideally to the extent that the portion of your domain you're modeling is actually a class hierarchy.