I agree, but his example is strong. While calculating something every time the mouse moves would be expensive and memoization is probably a good idea, the mouse pointer in most situations has some locality, and so some LRU cache is probably a better approach. There's probably examples where you'll get more bang for your buck using a different cache storage as well.

Does that mean in general their memoization function is flawed because it doesn't support that, no. If you need such specialization, for optimization, you're free to roll your own--which is why I agreed with you.

I don't know what definition of memory leak the author is working with, but a real memory leak occurs when all references dynamically allocated chunk of memory are lost without free()ing the memory. An unbound cache does not fit this definition.

The term "memory leak" is also sometimes applied, particularly in GC environments, to mean "memory that is still referenced, but will never be used again".

Poorly-thought-out caching is an easy way to do that, especially if the cached values themselves have a chain of references to other values.

With caching I don’t think you can assume any values are sure to never be used again.

Yes, there are some situations where circular references to DOM elements and the like will cause reference count based GC engines to leak memory. But an unbounded cache does not fit that description. It could be poor memory usage but not a memory leak.