The key thing to consider is block scoping in JS. Inside of that loop is a different scope, so any `const` defined in there is not accessible or interfering with higher scopes.

In a way it makes good semantic sense if the value shouldn't change within that scope.

As others have mentioned, in JS this is kind of questionable since arrays and objects don't behave as many would expect a constant to behave.

You're free to use either one, really - it largely comes down to preference.

the example in my link shows:

    for (const form of document.forms) {
        const formInput = form.querySelector('input')
        const button = form.querySelector('button')
        const state = form.querySelector('.state')
        ...
    }

formInput, button and state are modified in _each_ iteration.

Yep, and each iteration replaces the previous one. Think of each iteration as its own scope.

If you want to persist a const across iterations, you'd define it in a scope above it. You could also modify a let variable defined a parent scope. Personally I avoid doing that, but it's possible. Anything defined in an iteration though, I'd consider disposable unless it's a reference to and outer scope variable.

Someone correct me if I'm wrong!

I think you're right! And the value of doing it this way is that you cannot re-assign these names within the scope: they are const on each iteration of the loop.

I think more correctly, they're re-defined from scratch on every iteration. The previous const is no longer relevant on the next iteration

const isn't actually a constant as you probably know it. It's just that the reference is constant, not that the value is constant. Besides the point, but I guess good to clarify.

And yeah, you can use let/const, doesn't really matter except for performance optimizations, which depends on browsers and what patches they deployed that day anyways. Effectively, the difference is +-0.

`let` you usually use to signal that the variable will change in the future, within the scope. `const` usually signals the opposite. As the variable defined as a `const` here does not change within that scope (each loop is it's own scope), I think it's appropriate to use a `const` here.

There are, of course, different opinions on this. If you would rather use `let`, there's no reason why you shouldn't.

The rule behind `const` still applies within a loop, which is merely another block like any other. If you don't expect a variable to change in a given iteration of a block, whether it's a loop or via a function call, `const` is technically safer in that it will result in an error. It's all about providing the developer better clues to fix issues. Without `const`, it may be harder to diagnose why a value isn't what it should be. But if you're comfortable using `let`, then by all means.

Basically all uses of const in JavaScript are pointless. I have asked many times for someone to show me an example of a bug that shipped that would have been prevented by const as it exists in JS. I'm still waiting.

The only time I can think of where const is useful is in Vue 3, it lets you ensure that you remember to change myref.value instead of trying to reassign myref by mistake. But it's just sort of a coincidental side effect of the fact that Vue reactivity has to work by mutating properties and not rebinding names. Plus Evan You is experimenting with a syntax transform to make it not necessary to use .value anyway.

>Basically all uses of const in JavaScript are pointless. I have asked many times for someone to show me an example of a bug that shipped that would have been prevented by const as it exists in JS. I'm still waiting.

You have it backward; there's almost never a need to use let in JavaScript, as most variables should never be reassigned.

I've seen bugs pop up many times in client-side development where, for whatever reason, a variable is reassigned in a way that's difficult to predict. By defaulting to const unless reassignment is necessary, you're essentially putting documentation into the actual code and you can prevent logic errors by forcing runtime errors during development.

> as most variables should never be reassigned.

Why not? Reassigning globals can lead to bugs, sure. But when does reassigning a local lead to bugs?

> By defaulting to const unless reassignment is necessary, you're essentially putting documentation into the actual code

No, by defaulting to const, you're removing documentation. "Does this variable need to be kept safe from reassignment? Is it ever used again after this point in the code? Or is the developer just blindly using const for no reason?" Gotta read the code to figure it out because now const is just meaningless noise.

The same argument has been used against the use of TypeScript, and it is a fair argument. If someone has never had a problem involving types, or a variable being mistakenly set to the wrong value, then they will have higher confidence in not using TypeScript or the `const` keyword.

`const` isn't exactly that useful, especially considering that the tooling most of us use now helps us catch these sort of mistakes before runtime, but there's basically no objective reason to not use it. If you have a value that you don't want to change, `const` is only a few extra bytes from `let` and will provide better feedback when your tests fail because a value was subsequently set when it shouldn't have been. Maybe that never happens to you, but just because it's a rare problem doesn't mean it's useless to take a precaution. Most of us will never get into a car accident, but that doesn't mean that airbags are useless.

It doesn't change every iteration, it is declared anew for every iteration.

The value is constant for each iteration: they don't want formInput to change on line 43, for example.

As others have said, each time through the loop ‘resets’ the scope.

But on this subject, at this point, my rule of thumb is to always use ‘const’ first, until I find myself in a situation where I’m forced to change it to ‘let’.

If I’ve gotten into a situation where it seems like I need to use a ‘var’, then I seriously take a minute to rethink the implementation :)

Each iteration is a new scope, so you need to redefine the variable. If you used an if statement to define the variable in only one iteration of the loop, then the reference will be undefined in future iterations.

In the scope of the for loop, the reference will never be reassigned, so there is not point in using `let`. The scope changes for every iteration, so it is a different reference every time.

In C++, this may be even worse. Functions

int f(int k) { return k+1; }

and

int f(const int k) { return k-1; }

are considered different.