6 ms·

https://jamie.build/const https://jamie.build/const https://twitter.com/dan_abramov/status/1208369896880558080 https://twitter.com/dan_abramov/status/120836989

by sunseb 7y ago

https://jamie.build/const https://jamie.build/const https://twitter.com/dan_abramov/status/1208369896880558080 https://twitter.com/dan_abramov/status/1208369896880558080

futureproofd 7y ago
The OP article is common knowledge and is a copy of a copy of a copy. Your first link, on the other hand, is the perfect recipe for my Friday afternoon. Cheers!
- whowhatwhy 7y ago
  it's also wrong in the first sentence. there are at least 5 ways to define variables in js (edit: hint: globals)
saagarjha 7y ago
Does JavaScript have value types where const might work the way the first author expects it to?
- austincheney 7y ago
  No. The only thing that makes const unique from let is that references declared as constants cannot be reassigned or else an error will be thrown. The exclusion only applies to the reference name itself and not to any of its properties as the article articulates.
  - deleted 7y ago
    [deleted]
- threatofrain 7y ago
  In JS, I think of any reference to an object as a pointer, and the <pointer> is immutable even if its contents aren't; then everything in JS which can be considered a value which is immutable under const. IMO it's not just a problem of const vs let, because it'll pop up again when you're trying to copy a JavaScript object, and it'll pop up again when someone has questions about garbage collection.
- leftyted 7y ago
  symbol/boolean/string/number are immutable and work how you'd expect with const because they are immutable. Unsure if that makes them "value types". I think the article is a bit silly. Calling it "const" was a mistake but that's a naming issue. JS's "const" is the same as Java's "final," right? It communicates something useful.
- 52-6F-62 7y ago
  I won't repeat the other comments, but I'll note that you can make the additional, uglier step to get the results the first author expects by (as suggested) treating the assignment as a pointer to the object and rendering the object immutable. const myObject = Object.freeze({ myValue: "Something", }); The problem with that is `Object.freeze` doesn't act on nested objects, so you usually have to have some other method/macro to do that for you. You might be able to do that with decorators in TS. It works on Object and Array types, but not on other primitive types. That part is frustrating. It would certainly be nice to have a single method for rendering any value immutable, whether it was the initial assignment or a built-in.
- dragonwriter 7y ago
  JavaScript not only has (a small set of) value types, it also has frozen objects. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
the_other_b 7y ago
Lol that first read is fantastic. const doesn't do shit and we all know it Was a great intro, and absolutely true. Unfortunately I don't think this will catch on, although I agree with the author that it should.
- k__ 7y ago
  I like the reassignment prevention.
irrational 7y ago
I agree with Dan. I don't use var/const for much the same reason I don't use ==.
allenskd 7y ago
That's amazing. I was just scratching my head about const when I read the article, "so what's the purpose if I can change the value... but I guess I can't re-assign the variable with a new value .... that's it?" I still found the article incredibly informative, sadly as someone still stuck working on legacy apps it falls into "...in some near future I'll take advantage of JavaScript new stuff"
- Kaze404 7y ago
  If you're willing to add a build step to the project, Babel will let you use all the new features and compile down to whatever version you need.
  - allenskd 7y ago
    Thanks, I've never checked out Babel. I will truly suggest that to my lead, seems something we can take advantage of.
- karatestomp 7y ago
  > That's amazing. I was just scratching my head about const when I read the article, "so what's the purpose if I can change the value... but I guess I can't re-assign the variable with a new value .... that's it?" If the value is a primitive, you can't change it. If the value's a reference you also can't change that, but of course you can modify whatever that points to. Is that what's bugging people about this?
  - allenskd 7y ago
    I believe so. I don't make a big issue out of it... but anything carrying the word const I expect it to be fully read-only with no "buts" in between throughout the whole execution of the program. I guess if they used "readonly" as C# it would make more sense?
mgraczyk 7y ago
I think one important point that Dan and others miss is that `const` enforces a single-assignment style of variable naming that many find preferable. It makes it easier to read and forces people to provide more thoughtful names for their variables. I'm not saying that this behavior is enough to justify using `const` everywhere, but it should be weighed in any judgement about style.
eyelidlessness 7y ago
IMO the article's conclusion is wrong. We should indeed use `const`, and we should indeed use it to communicate. But the thing we should use it to communicate is different than what the article proposes. We should use `const` to communicate that we don't intend to reassign or mutate the variable. And we should do that by default unless there's a compelling reason to do otherwise. I know it can't be fully enforced, because JavaScript is designed for mutability of objects by default. But it is an implementation style that is almost always achievable in plain ES6 without too much trouble, and it makes more reliable software that's easier to reason about.
- _bxg1 7y ago
  And in TypeScript you can at least pair it with Readonly<...>, though that unfortunately still isn't recursive
  - ht85 7y ago
    Nice plugin to make sure you never mutate: https://github.com/jonaskello/tslint-immutable/tree/master/test/rules/no-object-mutation https://github.com/jonaskello/tslint-immutable/tree/master/t... You can add a rule based on the name of the variable to allow mutating (e.g. naming it `mutableSomething`)
    - _bxg1 7y ago
      Interesting, but not really tractable if you have to manually add every single variable to the rules config.
      - chaorace 7y ago
        The plugin allows pattern-based exceptions. For example, if your rule excluded variables with a "mutable" prefix, you could name your variable mutableSomething and it will be automatically ignored by the linter
hombre_fatal 7y ago
I'm not sure what either link clarify. The first link is someone confusing reassignment mutability with value mutability, a common beginner mistake when they read the byline of "const". It's like reading a rant about how { ...obj } only does a shallow clone and thus "doesn't do anything and we all know it" because you can still modify `obj` to modify the new object. The second link, a tweet, gives no reasoning.
russellbeattie 7y ago
Those links are beautiful. It's nice knowing someone else out there has some sense. It makes me feel less alone. But sadly the pedants won't let this go. The misuse of const is already documented as The Right Way, baked into libraries and live in production in millions of places. Sad but true. I'd love to do some GitHub sleuthing and find the first few developers out there to publish a project that misused const in their code, so we could tar and feather them. Though obviously being some sort of fad or mass delusion, it wasn't entirely their fault.
karatestomp 7y ago
I read a whole bunch of that tweet thread and got nothing out of it. What's wrong with const? Been using it for quite a while now, seems fine, no trouble. What am I missing?

by sunseb 7y ago

https://jamie.build/const https://jamie.build/const https://twitter.com/dan_abramov/status/1208369896880558080 https://twitter.com/dan_abramov/status/1208369896880558080

futureproofd 7y ago

The OP article is common knowledge and is a copy of a copy of a copy. Your first link, on the other hand, is the perfect recipe for my Friday afternoon. Cheers!

whowhatwhy 7y ago
it's also wrong in the first sentence. there are at least 5 ways to define variables in js (edit: hint: globals)

saagarjha 7y ago

Does JavaScript have value types where const might work the way the first author expects it to?

austincheney 7y ago
No. The only thing that makes const unique from let is that references declared as constants cannot be reassigned or else an error will be thrown. The exclusion only applies to the reference name itself and not to any of its properties as the article articulates.
- deleted 7y ago
  [deleted]
threatofrain 7y ago
In JS, I think of any reference to an object as a pointer, and the <pointer> is immutable even if its contents aren't; then everything in JS which can be considered a value which is immutable under const. IMO it's not just a problem of const vs let, because it'll pop up again when you're trying to copy a JavaScript object, and it'll pop up again when someone has questions about garbage collection.
leftyted 7y ago
symbol/boolean/string/number are immutable and work how you'd expect with const because they are immutable. Unsure if that makes them "value types". I think the article is a bit silly. Calling it "const" was a mistake but that's a naming issue. JS's "const" is the same as Java's "final," right? It communicates something useful.
52-6F-62 7y ago
I won't repeat the other comments, but I'll note that you can make the additional, uglier step to get the results the first author expects by (as suggested) treating the assignment as a pointer to the object and rendering the object immutable. const myObject = Object.freeze({ myValue: "Something", }); The problem with that is `Object.freeze` doesn't act on nested objects, so you usually have to have some other method/macro to do that for you. You might be able to do that with decorators in TS. It works on Object and Array types, but not on other primitive types. That part is frustrating. It would certainly be nice to have a single method for rendering any value immutable, whether it was the initial assignment or a built-in.
dragonwriter 7y ago
JavaScript not only has (a small set of) value types, it also has frozen objects. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

the_other_b 7y ago

Lol that first read is fantastic. const doesn't do shit and we all know it Was a great intro, and absolutely true. Unfortunately I don't think this will catch on, although I agree with the author that it should.

k__ 7y ago
I like the reassignment prevention.

irrational 7y ago

I agree with Dan. I don't use var/const for much the same reason I don't use ==.

allenskd 7y ago

That's amazing. I was just scratching my head about const when I read the article, "so what's the purpose if I can change the value... but I guess I can't re-assign the variable with a new value .... that's it?" I still found the article incredibly informative, sadly as someone still stuck working on legacy apps it falls into "...in some near future I'll take advantage of JavaScript new stuff"

Kaze404 7y ago
If you're willing to add a build step to the project, Babel will let you use all the new features and compile down to whatever version you need.
- allenskd 7y ago
  Thanks, I've never checked out Babel. I will truly suggest that to my lead, seems something we can take advantage of.
karatestomp 7y ago
> That's amazing. I was just scratching my head about const when I read the article, "so what's the purpose if I can change the value... but I guess I can't re-assign the variable with a new value .... that's it?" If the value is a primitive, you can't change it. If the value's a reference you also can't change that, but of course you can modify whatever that points to. Is that what's bugging people about this?
- allenskd 7y ago
  I believe so. I don't make a big issue out of it... but anything carrying the word const I expect it to be fully read-only with no "buts" in between throughout the whole execution of the program. I guess if they used "readonly" as C# it would make more sense?

mgraczyk 7y ago

I think one important point that Dan and others miss is that `const` enforces a single-assignment style of variable naming that many find preferable. It makes it easier to read and forces people to provide more thoughtful names for their variables. I'm not saying that this behavior is enough to justify using `const` everywhere, but it should be weighed in any judgement about style.

eyelidlessness 7y ago

IMO the article's conclusion is wrong. We should indeed use `const`, and we should indeed use it to communicate. But the thing we should use it to communicate is different than what the article proposes. We should use `const` to communicate that we don't intend to reassign or mutate the variable. And we should do that by default unless there's a compelling reason to do otherwise. I know it can't be fully enforced, because JavaScript is designed for mutability of objects by default. But it is an implementation style that is almost always achievable in plain ES6 without too much trouble, and it makes more reliable software that's easier to reason about.

_bxg1 7y ago
And in TypeScript you can at least pair it with Readonly<...>, though that unfortunately still isn't recursive
- ht85 7y ago
  Nice plugin to make sure you never mutate: https://github.com/jonaskello/tslint-immutable/tree/master/test/rules/no-object-mutation https://github.com/jonaskello/tslint-immutable/tree/master/t... You can add a rule based on the name of the variable to allow mutating (e.g. naming it `mutableSomething`)
  - _bxg1 7y ago
    Interesting, but not really tractable if you have to manually add every single variable to the rules config.
    - chaorace 7y ago
      The plugin allows pattern-based exceptions. For example, if your rule excluded variables with a "mutable" prefix, you could name your variable mutableSomething and it will be automatically ignored by the linter

hombre_fatal 7y ago

I'm not sure what either link clarify. The first link is someone confusing reassignment mutability with value mutability, a common beginner mistake when they read the byline of "const". It's like reading a rant about how { ...obj } only does a shallow clone and thus "doesn't do anything and we all know it" because you can still modify `obj` to modify the new object. The second link, a tweet, gives no reasoning.

russellbeattie 7y ago

Those links are beautiful. It's nice knowing someone else out there has some sense. It makes me feel less alone. But sadly the pedants won't let this go. The misuse of const is already documented as The Right Way, baked into libraries and live in production in millions of places. Sad but true. I'd love to do some GitHub sleuthing and find the first few developers out there to publish a project that misused const in their code, so we could tar and feather them. Though obviously being some sort of fad or mass delusion, it wasn't entirely their fault.

karatestomp 7y ago

I read a whole bunch of that tweet thread and got nothing out of it. What's wrong with const? Been using it for quite a while now, seems fine, no trouble. What am I missing?