- You don't have copies of the functions. 

- With delegation we have a dynamic (runtime) linkage between objects and their methods. With classes we have a "snapshot" copy of the relation. If I change the "parent" the child doesn't get updated. 

You can implement classes with delegation, but you cannot implement delegation with classes. 

What are the tradeoffs?

- Shadowing is awkward. 

- Everything is public in prototypes. unlike in modules. In practice, in his jobs so far, in most codebases he saw very deep, nested, very intricate hierarchies and in the end they just mostly used one instance of it... (modules would have been much simpler)

People try to use the class patterns, but don't take any advantage of it all. 

In his work, 95% of the time, he's using modules, because he doesn't need to instantiate several copies of an object. 

- Very rarely has hundreds of objects. It's not that common in real world code (you don't have 100 calendar widgets on a page).

Marc says that he often builds complex interfaces where he has several dozens instances of a (UI) element. 

Kyle says that if you have a 5-7 or a dozen item, modules suffice. The engine can optimise this easily. You need to have 500 of the same UI item to be able to benchmark meaningful difference with delegation. Even if an item has 50 methods. The JS engine is very good at optimising these cases.