Take the 2-minute tour ×

When I develop in JS, I'm frequently faced with the choice between capturing variables with an inner function (closure) and using an object.

Inner function:

var x = ...;
var f = function() {
    // use x here


obj.x = ...;
obj.f = function() {
    // use x here

The inner function approach "feels" more natural, but I was wondering - are there performance implications to worry about doing it one way or another, and what is the most idiomatic way to do this kind of thing?

share|improve this question

closed as primarily opinion-based by Barmar, Chris Baker, Ja͢ck, Joe, joran Jun 27 '13 at 0:57


So x, f and obj would be in some local scope? Please declare that. If not, this question would just be about namespacing. Also, how do you access the x in the second variant? –  Bergi Jun 26 '13 at 23:00
Micro-optimizations are virtually never worth worrying about. If the only concern or difference between two methods is memory micro-management, then you should just use whichever method you prefer. To me, there are usually clearly delineated reasons to use a closure vs. placing properties on an object. Memory is never a factor for me in deciding which approach to use since you don't really manage memory in javascript the way you may in other languages. –  Chris Baker Jun 26 '13 at 23:00
This article may be of interest: developer.mozilla.org/en-US/docs/Web/JavaScript/… –  Chris Baker Jun 26 '13 at 23:03
If you use a closure, you are restricted by scope so you might end up with many closures at the top level scope and all functions as descendents of that scope. With the object approach, you can more easily access values that are set in other scopes which should improve moudlarity of code. Of course there is no one approach that suits every case. In any reasonably complex application you will very likely use a combination of both approaches. –  RobG Jun 26 '13 at 23:30

2 Answers 2

up vote 2 down vote accepted

In an era where an average PC has 8GB of RAM, memory use by closures vs object properties seems irrelevant. In any case, it is extremely unlikely in a non–trivial application that it will make sense to use only use closures or only property values.

If you have a code module, it makes sense to use closures for variables that are only used internally by methods of that module. It also makes sense to use properties for values that need to be shared across modules without needing to use getters and setters (e.g. where you want to use obj.property rather than obj.getProperty()).

Also, property access is much more efficient than using a function to retrieve a value, but getters and setters can provide significant functionality (e.g. value validation and integrity checking) over simply reading or assigning a value.

As always, use what suits your application according to whatever criteria seem appropriate (speed, code maintainability, robustness, cross browser support, etc.).

share|improve this answer
I pretty much figured there wouldn't be a large performance impact for most applications. Thanks for outlining use cases of each. It sounds like in general there is no consensus on one being better or worse, just complimentary. –  gerty3000 Jun 26 '13 at 23:45
It has nothing to do with the available of RAM as you will not just get it all for your tab like that. In Chrome you have 1gb limit for example. It has to do with GC pressure and the more memory you use the slower you get. You will not be able to do server side apps or any javascript rich (games, editors, video stuff, not forums or CRUD) apps like this. The claims about method calls are also pretty much wrong because you can easily write code in a way that invites function inlining for such cases. –  Esailija Jun 27 '13 at 0:38
@Esailija—the point is that given the amount of RAM available, the difference in memory use between closures and object properties is irrelevant for most purposes. What do you mean by "like this"? Are you talking about function inlining at the code or compiler level? Can inlining be used as a general strategy for getters and setters as access to all shared data (i.e. both within and across modules)? –  RobG Jun 27 '13 at 3:22
@RobG "like this" means the way you see people sometimes make their classes by putting the methods inside the constructor. By inlining I mean the inlining optimization done automatically by modern engines whenever possible. The specifics depend on the engine, here are some limitations for V8 and for SpiderMonkey here, and here –  Esailija Jun 27 '13 at 11:18
Here's what I mean jsfiddle.net/LG8rB –  Esailija Jun 27 '13 at 11:30

Well in fact you allocate extra object in the second case, otherwise they look the same to me.

Functions are first class objects in JS and it's easy to forget that anytime you see function(){} that allocates a new function object which is relatively fat. You could think of it as seeing new Function() being called if that makes the object allocation more obvious to you.

This is only harmful when you have a "constructor" that defines functions inside it and returns an object pointing to those functions. Each of those functions is a separate object created on top of the object you are creating from the constructor. The functions will easily take 10-100x more memory than the object and its data itself, depending on the data and amount of methods of course.

If you are writing an application it's easy to consider whether you will ever have to worry about it. If you know your application will never create many objects at all then the waste of memory isn't so bad in the bigger picture. If you are writing a general purpose library etc, please don't make these assumptions for application developers whose needs you cannot predict.

share|improve this answer
