4

Lol. In the years that `const` and `let` have been in Javascript, not once have they ever helped me read the code better or caught a bug. They have not helped me understand anyone else's code, nor have they really helped convey any sort of meaning for other developers that I have heard.

Usually the rule is, const first, then change it to let if you need to. It adds nothing.

All this gold plating is weighing things down.

Comments
  • 7
    Because you never read real fucked up legacy code where hoisting is used (by accident. Nobody can tell me that someone _uses_ hoisting because they want to).

    I guess the deal with const and let is optimization. Const is a guarantee that the variable is never set again after initialization. Plus no hoisting. Hoisting sucks. Did i talk about hoisting already?

    Next: scope. A const/let variable is only defined for the block it is defined in (in a for loop for example).
  • 0
    @nitwhiz I do, and the issue isn't with hoisting. I'm glad that's gone, but they could have gotten rid of that without const and let.

    Const and let were added specifically for code readability, not optimization. It is trivial via SSA form to see which variables are modified and which are not; no optimizations are happening because of const or let.
  • 1
    It's a really hard and long process to change something like hoisting to something less forgiving if you wish to ensure backwards compatibility, which is also part of the reason for `let` rather than just introducing `const` and changing hoisting for `var`.
  • 2
    @Flygger They could have created a new directive akin to use strict. That would have made more sense IMO.
  • 5
    Whatever man, I like ‘em. Const ftw!
  • 0
    I don't mind them, but that isn't the point. Since then, the TC39 committee has had a real knack for adding weird things that didn't need to be in a scripting language. WebAssembly makes way more sense, as much as I dislike the direction all of this is headed to begin with.
  • 1
    Even though `const` is supposed to be a guarantee that it's never set again, tbh everyone just changes it to `let` as soon as the first TypeError gets thrown, thus its semantic meaning isn't really practiced. My code would not change at all if every declaration was changed to a `var`. I'm kinda glad that `let` has a block scope, but other than that I see no utility in them.
  • 1
    @junon

    It was added only for readability?

    Then why limit the scope?
  • 0
    @N00bPancakes Hoisting was an issue they wanted to fix anyway, and could have done so using a directive like I said before. But instead, the whole "immutable everything" fad was popular at the time and thus there was a strong push for const variables and readability.
  • 0
    @junon

    So it wasn't just for 'readability'....
  • 0
    I really enjoy the absolute mutability you get by using const with objects; any content in the object can be changed, added, or removed, but the object itself can never be overwritten :)
  • 0
    @N00bPancakes Well, it didn't really help immutability now did it?
  • 0
    @junon helped with scope...

    The whole conversation seems like 'this is dumb if we ignore a lot of stuff'.
  • 1
    @N00bPancakes

    https://twitter.com/dan_abramov/...
    https://medium.com/javascript-scene...

    Both agree with me that they provide little more than constant bindings.

    https://web.archive.org/web/...

    The spec draft mentions scoping, but as I said earlier, they could have approached this entirely differently. We had linters before const/let, too, that enforced that we used proper coding standards, just like we do now.

    Sorry, but my original point is still. a hill I'm dying on.
  • 0
    @fuckyouall

    I'm not saying it is a great solution or not wrong but 'this wasn't about that' when it was ... there you go.
Add Comment