3 ms·

Captured objects in closures are another problem in JavaScript. A long time ago I was using a JavaScript framework where the memory usage went up steadily as

Captured objects in closures are another problem in JavaScript. A long time ago I was using a JavaScript framework where the memory usage went up steadily as you navigated the single page app. One cause was captured variables (referencing large object trees) in event handlers. The only viable way to fix the issue was to write my own custom framework taking extreme care with closures and sometimes nulling variables (the code for the existing framework was just too complex to fix - and memory references are hard to debug in browsers). I saw the same issue with memory usage growth in a different framework. Some of the issue was that Internet Explorer had problems with circular references between JavaScript and the DOM, but the captured variables in closures were their own problem.

jauntywundrkind 3y ago
I wish js would have made this first class. The function/closure should expose a .meta.captued or some such that exposes the bindings it holds. And ideally we should also be able to clone the function-with-closure. And modify the bindings. This wouldn't have eliminated many foot guns, but it would have been cool & would have let us dive deeper into the machine.
- robocat 3y ago
  I can't see how that would work. The arguments variable is already hard to use (accessing it from within the function hardly helps you, and giving access to it by using it as a parameter to another function, or using another closure to capture it doesn't help you either). Apart from the fact that your idea would severely interfere with optimisations (e.g. causing JIT problems, and interfering with variable liveness analysis) - just like some other dynamic features do.
  - jauntywundrkind 3y ago
    You'd need a dependency graph of optimizations, to understand where a new dependency would cause other optimizations to need to potentially be disrupted. This doesn't seem like a hardfast cant. We keep getting arguments against doing stuff because it might not be performant. I don't disregard those concerns entirely. But I think we also over-actively forbid, we prematurely optimize by pruning possibility, all too often.

jauntywundrkind 3y ago

I wish js would have made this first class. The function/closure should expose a .meta.captued or some such that exposes the bindings it holds. And ideally we should also be able to clone the function-with-closure. And modify the bindings. This wouldn't have eliminated many foot guns, but it would have been cool & would have let us dive deeper into the machine.

robocat 3y ago
I can't see how that would work. The arguments variable is already hard to use (accessing it from within the function hardly helps you, and giving access to it by using it as a parameter to another function, or using another closure to capture it doesn't help you either). Apart from the fact that your idea would severely interfere with optimisations (e.g. causing JIT problems, and interfering with variable liveness analysis) - just like some other dynamic features do.
- jauntywundrkind 3y ago
  You'd need a dependency graph of optimizations, to understand where a new dependency would cause other optimizations to need to potentially be disrupted. This doesn't seem like a hardfast cant. We keep getting arguments against doing stuff because it might not be performant. I don't disregard those concerns entirely. But I think we also over-actively forbid, we prematurely optimize by pruning possibility, all too often.