
A toddlers guide to memory leaks in JavaScript - kushan2020
https://medium.com/@kepta/a-toddlers-guide-to-memory-leaks-in-javascript-d5a592c7bec1
======
kbart
This article does a really poor job explaining what memory leak is and barely
even mentions JS specific pitfalls (what could be expected by reading a
title).

~~~
kushan2020
It is called toddlers guide for a reason. It’s meant to be a very gental
introduction and I try to avoid going knees deep into the topic. There are
references to other great articles which tell you about pitfalls.

------
marcusarmstrong
This is just “using lots of memory”, not a “leak”.

~~~
taneq
In the context of a language with a working garbage collector, doesn't "memory
leak" just mean "accidentally using lots of memory"?

~~~
AstralStorm
With cyclical references add "freed sometime between now and eternity".

If this is not a definition of a memory leak I don't know what is.

~~~
taneq
Well no, cyclical references only stop the object from being deleted if it's
still accessible. That's what the 'mark' part of 'mark and sweep' does - it
marks all objects still accessible somehow from inside the program. Then the
'sweep' bit runs through all allocated blocks and frees the unmarked ones.

Now, if you're merely approximating garbage collection with reference counting
then sure, you have a problem.

------
tehlike
Just monitor your production memory profile, and occasionally run load test on
your app. It is fine.

------
spentdeath
All of these issues could’ve been avoided if we didn’t use functional
programming. I think imperative languages are better because things like
memory leaks and algorithmic errors are easy to conceptualize in the first
place, hence less chance of typos.

~~~
myhf
All of these issues could’ve been avoided if we didn’t use imperative
programming. I think functional languages are better because things like
memory leaks and algorithmic errors are easy to conceptualize in the first
place, hence less chance of typos.

