
Drool: automated memory leak detection in JavaScript - fdb
https://github.com/samccone/drool
======
wamatt
I found the author's reason for making this quite interesting

 _After running perf /memory tests across multiple todomvc implementations, I
found that almost all implementations have significant memory leaks on the
most basic of tasks. Worse yet, most of these leaks were introduced at a
framework level, or were introduced by "expert/(framework authors)". The
question arose in my mind, if people who authored a framework are introducing
leaks in the most trivial of applications, how can users be expected to create
non-leaking implementations of much more complex applications._

------
dcherman
Very cool! I was going to be sitting down soon to reason about the $compile
step in Angular 1 to see if there were any leaks. It'll be interesting to run
this against my test case and see what pops out.

Thanks!

------
hippich
Am I correct, this tool simply compares before and after number of nodes? Or
it is more capable and I am just missing something? I guess it is still
valuable for CI..

~~~
samsaccone
Hey Hippich, it currently gives you node count, heapsize, and eventListeners
after the action is taken and a "super" GC has been run
[https://github.com/samccone/drool/commit/4c3ac304448509afc08...](https://github.com/samccone/drool/commit/4c3ac304448509afc0827e34229999ecba707b04).

It is up to the consumer of the tool to decide what is really a failure and
what actions are "clean"

------
bestusername111
Am I the only one sick to death of fucking JavaScript? It's an abomination of
a "language" but loved my web devs because hurr durr anything other than web
is too hard for them.

