> the renderer hierarchy he created is yet another good example
> of why I believe coffeescript needs interfaces...
What exactly are you thinking of here? Because JS is as flexible as you can be in terms of duck-typing and calling any function with any number of arguments -- I don't see what having an explicit "interface" construct would gain you.
Compiler safety for the design. Implement a base class, and force implementation for sub classes. I know that CS philosophically is about keeping JS's openness, but I feel it would be a time saving convenience if the compiler told me I was missing a method.
If you want a language that compiles to JS and has more compile-time checking, I'd encourage you to check out Dart. It's not everyone's cup of tea, but if you don't mind semicolons and curly braces, it gives you a pretty decent amount of compile time checking while still generating nice JS.
Ah yes -- this would be very against the open/dynamic spirit of CS and JS -- and for that reason, we'd never add it. Many valid uses of subtypes don't need to implement every method defined by a parent type (or interface) in order to be used correctly.
For example, a rich "collection" interface that has some helper functions for key:value hash-like collections, but that a more array- or set-like subtype doesn't have to implement.
If you forget to implement a method that you later try to use, you'll find out when you try to use it. Such is the nature of the beast.