Some of these (heap dumps) can also be used with nodejs. That being said, from my experience most UI developers do not care much about memory leaks,most likely because the assumption is that a page is not long running enough that's it would matter.
#include <stdio.h>
#include <stdlib.h>
int main(void) {
size_t sz = 0;
void *unused = NULL;
for(;;) {
int n = 0;
void *tmp = realloc(unused, ++sz);
if(!tmp) break;
unused = tmp;
puts("Enter a number and I'll double it, or enter 0 to end:");
scanf("%d", &n);
if(!n) break;
printf("%d\n", 2*n);
}
free(unused);
}
He kept delaying on giving me code until the client (and I) got upset enough. The code he gave me was garbage despite his claims of really knowing Javascript (very good interviewer...). It was horribly slow, unfinished and I spent two weeks trying to comprehend it so I could make a decision as to throw it all out or patch it.
One of the biggest problems turned out to be a function or something (details are fuzzy) that was generating a object that corresponded to the data/information the user would see in the UI. His code was not tracking whether a specific object had already been generated (i.e. no need to generate a new copy if the data was already been shown) so in the end, far too many copies of these little objects were being created - and kept around.
So it was a memory leak, but the memory wasn't getting lost, just forgotten about (if that makes sense). Enough time and the browser would get really slow, etc. Thank god for infinite RAM! (not)
Fortunately I learned my trade fixing problems with Borland's heap management (don't ask me for any details, that was 30 years ago) so I had the leet skills and patience to track down every last byte of RAM... This was before any fancy tools from Chrome were available, AFAI remember.
Never used Valgrind or know what the current state of the art is in regard to web dev / Javascript, but keeping track of RAM usage in Javascript (or Python or ...) is always a necessary task to pay attention to.