Hacker News Reader

Comment by xhkkffbf | Hacker News Reader

I've worked with JavaScript weenies who are in love with the const declaration. They don't have an answer, though, when I ask, "Shouldn't the compiler be able to notice that a variable isn't changed in it's lifetime?" Most of the const values are just local and never leave the function but the weenies continue to stomp their feet when I use "var".

The compilers are smart. Let them do their thing.

View on HN

For JavaScript const is more for letting the developer know intent. If I declare a local variable within a function with const, I am saying this variable should not be reassigned. If I use let I am saying that the variable can be reassigned.

It's nice when looking at someone else's code and being able to tell if they intended to have a variable be reassignable or not.

Maybe you've talked to JavaScript devs who are just bad at explaining their reasoning or maybe they just strictly adhere to linters which encourage the use of const and let and throw linting errors when they come across a var.

Either way, I'd recommend you reevaluate your language and refrain from calling other dev's weenies just for having a different opinion than yours and maybe not being able to properly explain their stance. Using language that borders bullying is not helpful, it's no better than calling someone a snowflake or other degrading term.

Const is primarily for documentation to indicate that the assignment happens only once and won't be redefined. Using 'let' or 'var' indicates to the reader that the variables value will be reassigned in the function.

It's not about the compiler.

Also let/const don't get hoisted to the start of the function, declaration using var does.

Comparing "const" and "var" is incorrect; the former is block-scoped (like "let"), while the latter is function-scoped.

More to the point, "const" in JS is a maintainability tool to prevent accidental reassignment. I don't think people use it for performance reasons, nor should they.

Actually no, compilers can't assume that `foo` is const.

    var foo = 0;
    eval("foo = 1");

With that said, virtually nobody uses `const` for performance reasons, but for developer readability and avoiding mistakes.

A javascript engine can tell that a variable is used in a const-like way if it statically checks that `eval` is not used in the within the variable's scope. I believe there are a few optimizations in V8 and other engines that are disabled if eval is used in the scope at all. (I don't know if there are any optimizations around a variable being used in a const-like way. As you said, const in JS is mainly for developers.)

Given code like `function foo(fn, str) { var foo = 0; fn(str); return foo; }`, you might be wondering what happens if foo is called with `foo(eval, "foo = 1");`. The answer is that a standard eval call isn't actually a normal function call but better understood as a special syntax resembling a function call. There's a big difference between `eval(x);` and `var e = eval; e(x);`. When you take the value of `eval` (by passing it as a parameter or assigning it to a variable, etc), the value you get is actually the "indirect eval" function, which works slightly differently than standard eval: it does not get access to the local scope that it's called in. This means its usage won't break any optimizations that assume the local scope won't be modified.

> Actually no, compilers can't assume that `foo` is const.

They can assume it, they just need to be able to reverse that assumption if you do change it through something like eval. This is called 'speculative optimisation' and we use it to optimise languages like JavaScript, Ruby, Python, etc.

your question only makes sense if they are using const for performance reasons... which I don't think anyone does. No real reason for using var anymore over let in production code. I'll still use var in the console for testing stuff.

It tells the reader something too. There's no excuse for var anymore.

I've not seen this as the basis for the default usage of const over var (or let) in javascript. The primary reason that I'm aware of is that if you use const by default, the compiler will tell you if you accidentally re-define the value of a variable. Possibly because people feel that immutability by default reduces error frequency, though I don't have any data to back up that assertion.

Defaulting to more restrictive, less featureful constructs just seems like engineering 101.

const doesn't actually stop data from changing, just reassignment.

  const user = {id: 1, status: 'active'};
  user.status = 'disabled';

is valid javascript

You're talking about two different things. In this case, you'd use...

    const user = Object.freeze({id: 1, status: 'active'});

But const is immaterial to this topic, as it only prevents you from being able to reassign user to some other value, i.e.,

    user = 7;

While...

    let user = Object.freeze({id: 1, status: 'active'});
    user.status = 'disabled'; // throws an error.

Provides the behavior that you're seeking to guard against, regardless of let/var/const usage.

>You're talking about two different things. In this case, you'd use...

No, I'm talking about the behavior of const.

That is how object oriented languages work. It is a constant reference to a mutable object.

  final int[] arr = {1, 2, 3};
  arr[1] = 10;

is valid Java.

Which is to say that the const pointer itself doesn't change. It doesn't impose any constraints on the values of any underlying data structures.

Javascript could use some proper immutable types.

I've wondered why the JS people didn't call their keyword for this purpose "final" like Java did.

You use const because you want a runtime error if someone attempts to change it.

It's also documentation of intent.

Some code, for better or worse has very long functions, and you might use the variable 100 lines down from where it is declared.

Is a runtime error better than letting it silently change? Debatable, but the error is more likely to blow up a unit test, so you know there is a problem before you ship.

And needless to say: in Typescript you'll get a compile time error. In Typescript it's a no-brainer to use const when appropriate.

'const' in JS is 100% for readability and enables no additional optimizations above 'let'. In fact 'const' and 'let' are often worse than 'var' because of the temporal dead zone.

> In fact 'const' and 'let' are often worse than 'var' because of the temporal dead zone.

Seems like a massive overstatement. What are you even referring to as the downside?

For 99% of usecases/people, TDZ just means you get a runtime error for your use-before-declaration bugs.

The only reason I can see for using `var` is if you're doing some very confident performance hacking in a hot loop and you have the performance testing harness to prove that you're not just wasting your time.

> Shouldn't the compiler be able to notice that a variable isn't changed in it's lifetime?

The compiler can, I can't (efficiently). const spam also occasionally catches when I modify the wrong variable.

Reply on news.ycombinator.com