Live data from Hacker News

Encapsulation in Javascript

jonathan-jackson.net

1–10 of 18 posts

Re: Encapsulation in Javascript

#2
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.

Re: Encapsulation in Javascript

#3

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 num…

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.

Re: Encapsulation in Javascript

#4

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 num…

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.

Re: Encapsulation in Javascript

#5

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 num…

The module pattern has its place and can be used alongside prototypes, as you know, but I absolutely agree.

Re: Encapsulation in Javascript

#6

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 num…

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.

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...

Re: Encapsulation in Javascript

#7

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 num…

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.

Re: Encapsulation in Javascript

#8

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 num…

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.

[deleted]

Re: Encapsulation in Javascript

#9

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 num…

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

Post reply on HN