Encapsulation in Javascript(jonathan-jackson.net)
jonathan-jackson.net
Encapsulation in Javascript
http://www.jonathan-jackson.net/encapsulation-in-javascript
Thought that it was interesting and others might enjoy it as well.
3 comments
Not to be hyperbolic, but the continual promotion of the "module" pattern in JavaScript is some of the worst advice you can give.
JavaScript has prototypes for a reason -- use them. By using the "module" pattern to build objects, you create a separate copy of every function for every instance of every object you create. If you're just creating a handful of objects, it's no big deal, but if you're creating a large number of objects, it's horribly CPU and memory inefficient.
Modern JS runtimes like Chrome/V8 can create and store a million small objects with prototypes and "new" in a couple seconds, using just a dozen or so megabytes of RAM. Creating the same million small objects with the "module" pattern takes minutes, uses many hundreds of megabytes of memory, and often crashes the browser.
And that's just the pragmatics -- there are deeper semantic reasons to use real prototypes.
JavaScript has prototypes for a reason -- use them. By using the "module" pattern to build objects, you create a separate copy of every function for every instance of every object you create. If you're just creating a handful of objects, it's no big deal, but if you're creating a large number of objects, it's horribly CPU and memory inefficient.
Modern JS runtimes like Chrome/V8 can create and store a million small objects with prototypes and "new" in a couple seconds, using just a dozen or so megabytes of RAM. Creating the same million small objects with the "module" pattern takes minutes, uses many hundreds of megabytes of memory, and often crashes the browser.
And that's just the pragmatics -- there are deeper semantic reasons to use real prototypes.
I think the author mis-understands memory management. The following line argues that, without a reference to the prototype, the object is smaller:
"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 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.
I believe you are correct upon re-reading. I'll re-word this statement as soon as I have time. Thank you for bringing this up.
Yes I suppose that's true. I think it all depends on what your case is and preference, but yes memory is an issue with the module method. Just out of curiosity what are the best tools out there to test memory consumption of javascript snippets? It'd be interesting to see prototype/module/whatever_else memory usage side by side.
The browsers are getting better at optimizing memory use for small closures all the time, but there's still a long way to go. Here's a screenshot of the Chrome heap profiler for both cases:
http://cl.ly/A5NX
http://cl.ly/A5NX
I have one question. How to handle private methods in prototype/module pattern? If I declare private function in obj function declaration I can not access it in public functions attached to the prototype of obj. This is also true for module pattern. This problem arises when I need to add extra method later. How to overcome this situation?
You can use a heap snapshot in Chrome Dev Tools. It has a handy feature where you take multiple snapshots and it shows you the differences in memory usage between them. See: http://code.google.com/chrome/devtools/docs/heap-profiling.h...
I'll definitely be looking into that. Thanks.
[deleted]
This is all true. But people might be more convinced by the bigger reason: developer productivity.
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.
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.
You are not being hyperbolic. The promise of strong encapsulation is very compelling, but this pattern is only appropriate for Modules (hence the name).
I suspect many JS developers head down this blind alley and get burned.
I suspect many JS developers head down this blind alley and get burned.
The module pattern has its place and can be used alongside prototypes, as you know, but I absolutely agree.
CoffeeScript FTW. https://gist.github.com/1214296
"Module's are where it's at"?
Grammar much?
And don't get me started on "login with X, Y, Z". As a verb, it's "log in". YC has it wrong also.
Grammar much?
And don't get me started on "login with X, Y, Z". As a verb, it's "log in". YC has it wrong also.
Fixed the header "Modules are where its at" Thanks for bringing this up.
Argghh. Please correct it again, to
Modules are where it's at
I actually fixed it correctly on the website then typed it incorrectly in my reply to you.