Hacker News Reader

Comment by sunseb | Hacker News Reader

On a side note, I find crazy this obsessive-compulsive behavior to use `const` everywhere in modern JS codebase (even in Webkit now).

It solves really no problem (I mean, Python, Ruby and almost all other programming languages are doing fine without preventing against variable reassignment, and we can still reassign function parameters and object properties in JS).

So much brain power wasted on this useless thing.

Also using `const` everywhere is semantically misleading and ugly. It's not what you would expect in 99% of other programming languages out there.

View on HN

There are very few places where you ever need to use let or var. const is solving important issues

  - it has lexical scope instead var function scope
  - it does not hoist like var
  - it prevents accidental reassignment

Accidental reassignment happen more often in JS because of non-lexial scoping, weakly typed and async functions. Also, both Ruby and Python are "strongly typed" as opposed to weakly typed Javascript.

Let has lexical scope.

I’ve always thought const was something of a mid feature, as it doesn’t generally do what people think. He’ll back when Opera was an actual browser engine it just used const as an alias for var.

Immutability has been pretty hot of late, though still controversial. There are several popular languages which encourage or even force immutability (Elixir, Clojure). What sold me on the idea was Rich Hickey's talk, "The Value of Values": https://www.youtube.com/watch?v=-6BsiVyC1kM

I look at it as mostly a safety net: I'd rather use const by default, unless I have a good reason to be able to mutate the variable. (To flip it around: what problem does being mutable-by-default solve?) 9 times out of 10, I don't need to change the value for the lifecycle of the function; and often if I do, the code is cleaner anyway if I use an immutable pattern (such as `const foo = bar.map()` rather than `for(x in bar) foo.push()`). Thanks to the magic of Merkle trees, we can generally make fresh pointers without it costing much memory overhead.

I agree lukifer. Immutability is useful and interesting, but `const` in JS not really about immutability, it's about variable reassignment (which is trivial to handle really, even for a noob programmer).

const arr = ['foo'];

arr[0] = 'bar';

assert(arr[0] === 'bar'); // !!!

Something like that would make sense though IMHO:

const PHI = 1.618;

I don't get how JS is designed really, they try to solve a bad design (`var`) but they introduce another bad design (`const`) and they make things even messier. Many devs ship JavaScript thought TypeScript these days, so I hope Microsoft can clean this mess one day.

What about const/let is poorly designed?

Have a look here:

https://jamie.build/const

https://twitter.com/dan_abramov/status/1208369896880558080 (React core team member)

https://twitter.com/littlecalculist/status/91787524189167616... (Ember creator)

I don't think it's poorly designed, its just maybe perhaps not all that useful?

Some people seem really unhappy that it might mean a reference is constant, rather than a value, if the value happens to be a reference. If that makes sense.

The issue I have with `const` is not your original premise, but the one you allude to here: people confuse reassignment and immutability. Because of this, they end up using const/let to "signify that they're not changing a variable," when it doesn't actually matter anyway, because they're thinking of immutability but disambiguating reassignment capability. You can usually tell who has only a superficial understanding of the language by reading how `const` and `let` are used in their code.

Personally, I default to const, and use it pretty much 99.9% of the time. I use `let` in the few cases where it's actually useful to have a block-scoped variable. Ironically, this probably does a better job of "communicating" intent than the ritualistic obsession with "immutability" does, simply because you know if you're deviating from the default, there is a good reason for it.

Yeah, that's fair, I've been bitten by "not actually immutable" bugs before (works well enough for primitives, but not objects or arrays, which is most things in JS-land!). Libraries like Immutable.js can help bridge the gap.

> they try to solve a bad design (`var`) but they introduce another bad design (`const`)

`let` is intended to be the actual `var` replacement, and it's okay for that. I think there's an argument that `const` is a bad design, in the sense that it's deceptive, under the not-that-uncommon case you describe. Still, I'd rather have it than not, and I personally still like defaulting to `const` and opting-in to `let` in the (rarer and rarer) event that it's needed. (I'm also on 100% TypeScript at this point, which doesn't remove the potential for problems, but does provide an extra layer of guard rails in general.)

Yes, `let` is fine. I use `let` 99% of the time in my personal projects, it's more convenient, but I often must use `const` when working on an existing codebase. :(

Most of JavaScript devs do like you, they default to `const` and if they need to reassign the variable, they switch to `let`.

To me it feels more like a ceremony for declaring a variable than a rational and a useful practice. :)

It's part of type enforcement for me (note: I do my work in typescript); if you never intend to redefine it, make it a const, then you'll get an error if you try to redefine it later.

performance-wise, const is also around 20% faster than var, and usually faster than let (you can test it yourself: https://jsperf.com/let-vs-var-performance/67).

Edit: I forgot (because I always just write `const` anyway), but TSLint/VScode also default to bothering you to use const if you define a let/var and never re-define it.

> So much brain power wasted on this useless thing.

I can see the argument that using `const` over `let` doesn’t bring any huge benefits, but I don’t see what the harm is either. I never found it a waste of brainpower. At this point it’s idiomatic, so I think using `let` everywhere is more likely to have people confused.

It's nice until you want to reassign some global variable externally for in-production debugging via a browser console.

Reply on news.ycombinator.com