Encapsulation in Javascript

"The other way it differs from the constructor pattern is that the prototype class is not instantiated. Which reduces the memory consumption of the object (among other things)."

Admittedly, there is some ambiguity because the second statement is a fragment. The way Crockford is quoted seems to support this fallacy, though.

Echoing what jashkenas said: anything you may save on a reference to the function's prototype (minimal), you lose when creating copies of each member function.

What Crockford was speaking about in his post was using "new" directly on a function definition. In that specific case, the reference to the prototype is useless, since it is blank. In the OP's "Mammal" example, the prototype reference provides key functionality that is well worth the cost.

The module pattern boils down to trying to bring the ideas of privacy from Java into JavaScript. Java has good tools (IDEs) for interacting with, debugging, and testing objects with private data and methods. JavaScript does not.

Once you build your encapsulated module, you find yourself adding extra getters and setters to provide visibility to the code you're writing or testing. Then it turns out to be very convenient to use some of those in the API you export to other modules, and you may or may not remember to remove them before deploying, so you end up losing any supposed benefit of encapsulation.

I suspect many JS developers head down this blind alley and get burned.