I really doubt this is right at all, and this is not a good experiment to show that it is right.

1) You're not recording the heap before hand, so it's impossible to know how much has actually changed

2) You're not running multiple experiments. The garbage collector is not deterministic, so you'll get slightly different numbers each time. At the least, you should be reporting an average over many trials.

3) You're logging to the console in this experiment. Logging to the console expends huge amounts of memory and CPU which are going to make the results far too variable to be useful.

For the record, when I tried measuring the difference, I saw no difference; the amount of memory that had been used by any single run was basically random, and neither was more or less than the other.

Remember the three rules of optimization:

1) Don't.

2) Don't, yet. (Experts only)

3) Profile before optimizing. Even if this experiment showed that variables inside loops use more memory, that wouldn't justify the blanket advice to not declare variables in loops, because that's probably not where most of your program is using its memory; instead of hurting readability and violating best-practices, you should find where your program is actually wasting most of its memory.

For loop-internal variables, this shouldn't actually save any memory on average. I mean, if the garbage collector is really stupid (most aren't), it might, but not much unless you've got a lot of variables inside the loop that are only ever primitives. OTOH, it should save some time, because you don't have to allocate memory on every loop iteration.

For the actual counter variable though, it's not as clear cut. In terms of runtime and memory usage, there should be near zero difference in the totals between these two code samples:

let i
for (i = 0; i < 10; i++) {
    // do something
}

for (let i = 0; i < 10; i++) {
    // do something
}

The reason is simple: Internally, that first part of the loop expression (the i = 0 part) runs exactly once. So moving the counter declaration outside of the loop expressions just changes the scope, nothing else. Somewhat counter-intuitively, this may even make the loop run slower if you are accessing the counter inside the loop a lot (I know of no JS engine that actually has this issue, but a trivial naive implementation of the JS scoping rules would cause it to run slower).

If, however, you can safely reuse the counter variable across multiple loops, then you might save some time this way, but you won't really save much space long-term. The important part there though is 'safely', you usually have to at least scope the declarations to the containing function so that you don't end up manipulating other loops states accidentally, so you're not likely to save much time either unless you're doing a lot of looping.

Look, this article needs to be taken down. It's very harmful to novice programmers and more experienced programmers will probably just leave a comment saying "you're wrong". That being said, I feel bad for the author. He likely has no idea that this is bad advice and this is all probably discouraging. My advice for the author: please take the article down or revise it so that beginners don't draw incorrect conclusions. Afterwards, write your next article! I'd love to see you write about frontend or something else you're interested in!

In Javascript, there isn't a Garbage collector system, so you need to handle yourself the resources management part of your application, and this could be a big mess.

Why? JavaScript has automatic garbage collection mechanism.

Just don't write in JavaScript if you need fast and memory efficient code.

This thing is premature optimization. You should prefer code clarity over efficienty until you absolutely need last one (about 1% of your code I suppose).

Declaring variables outside of your loop to use inside of a loop could cause unintended consequences if the code in the loop is complicated. Reusing variables might seem efficient until you need to fix a bug introduced by another developer.

Unless performance is really essential and in this case it's probably negligible, writing cleaner code is more important imo.

Pretty much everything here is wrong.

The iterator should be stack allocated, and is only initialized once anyway.

The logString variable is assigned to a new value each iteration and goes out of scope at the end, or at least gets reassigned. There aren't 1000 variables with heap string references waiting to be deallocated when the loop ends.

There is an excellent explanation by v8 developers of how memory allocation works in v8 JS engine.

Whoa, this is crazy. I have always dismissed the declaration inside the loop having a very minimal performance impact. Apparently my assumptions were wrong.

Thanks for this! Will definitely take note of this from here on out.

Please don't do this and take this article down. As others have mentioned, the experiment is flawed.
Don't prematurely optimize. It can lead to a number of problems:

1. It becomes harder to read and understand
2. It can lead to future errors
3. Go after the big fish first. Find the performance bottlenecks first and fix those before worrying about the tiny things.

Don't complicate your code unless absolutely necessary. Follow the KISS principal.

I recently found myself reviewing code from a senior software engineer that was filled with premature optimizations. It was very hard to read and created an abundance of code for what purpose? Just to save a negligible amount of time - we're talking far less than a millisecond. Orders of magnitude less than your standard network delay.

Don't be that engineer.

Don't encourage others to be that engineer.