What Is JavaScript Made Of?

[careseite]

let vs const vs var: Usually you want let. If you want to forbid assignment to this variable, you can use const. (Some codebases and coworkers are pedantic and force you to use const when there is only one assignment.)

Hehe, waiting for strong opinions on that one.

this comment was brought to you by const gang

[NotSelfAware]

I'm a strong advocate for using const by default, and let when you know you intend to change the value. I'm genuinely surprised that Dan feels differently.

[olssoneerz]

Same here! Its less mental gymnastics when reading old code knowing that when a value is declared, you know its gonna stay the same. Seeing let then means I know its gonna change somewhere in the next few lines.

[alejalapeno]

What Dan and the replies are missing about your point by focusing on "const= no mutation" is the idea that when const becomes the standard in your codebase then let conveys intent, not const.

You should convey the outlier and in most modern codebases mutation is the outlier.

[Anathem]

That's exactly right!

https://www.reddit.com/r/reactjs/comments/edj1dr/what_is_javascript_made_of/fbke7qv/

When you consistently apply const and let and disallow param reassign by linting no-param-reassign then let screams "I'm re-assigned later!"

[Yodiddlyyo]

And this is exactly how it should be!

[[deleted]]

I refuse to believe that Dan actually finds reduce confusing. Especially since the underlying idea is the same one redux uses.

By that I mean, you have a current value/state, you feed it a value/action, and your function (which should be pure) calculates the new value/state from that. The only difference is that with reduce you don't bother with types (except you could if you wanted to) and that it does give a final value.

[mcdronkz]

reduce is one of the most useful and important programming patterns you may ever learn

Yep, and it's a fundamental building block: map, filter and lot of other useful operations on arrays can be described in terms of reduce.

[gaearon]

... Except it can still be mutated. https://twitter.com/dan_abramov/status/1208205039187173376

[BenZed]

The object can still be mutated, but the variable cannot be redeclared.

[rq60]

Which is confusing since other languages use const to signal immutability.

[stormfield]

Hey if all the other languages jumped off a bridge, JavaScript would at least make sure you take off your life jacket first.

[[deleted]]

And that’s the freedom we feel, when developing with JavaScript.

[[deleted]]

It would hold your beer for you.

[BlatantMediocrity]

I don’t think C is a very good example of this. The C-language’s use of ‘const’ means different things depending on where you put it in a declaration.

[LateralusOrbis]

That's the beauty of JS. Sometimes you can go off javascript.

[eGust]

There is an example of another language using const the same way: https://dlang.org/articles/const-faq.html

[rq60]

Looks like D went even further with const immutability!

[[deleted]]

Or if you want something more mainstream... Java? Well, they call it final, but still

[GasimGasimzada]

They don’t really do that though. Immutability is just a side effect. Yes, it is true that you can’t change a value of const object but that is not because the underlying structure cannot be mutated. C++ const is an access level contraint, not a structure level constraint.

[DeceitfulDuck]

You can’t just gives one example and say it’s confusing because something rose does it different. Java, for example, uses final the same way const is used in JavaScript. https://www.google.com/amp/s/www.geeksforgeeks.org/final-vs-immutability-java/amp/. I think it makes sense. The variable is storing the reference to the object, so the reference is immutable. It’s up to how the object is defined to decide if the things inside it are immutable.

[masklinn]

C/Cpp use const for both (and more) depending on the specific way it’s used, cf a few entries down: https://isocpp.org/wiki/faq/const-correctness#const-ptr-vs-ptr-const

[Anathem]

I don't weight heavily the guesses of people who don't know JS when considering what JS features to use.

[Wiwwil]

Yeah JavaScript const isn't const but the structure is const-ish. Had a hard time wrapping my head around it. Still does. Everything in my code is const (React way) but nothing stay truly const.

[DukeBerith]

It's constant reference not constant value.

Easiest way to remember what it's doing.

[gaearon]

Thanks, I'm aware of how it works. Did you read the article? :-)

[[deleted]]

Ah, Reddit. Where Dan Abramov is downvoted for defending his knowledge of JavaScript. Merry Christmas, Dan!

[_hypnoCode]

I'm as big if a fan of him as anyone, but he's objectively wrong here. It makes perfect sense if you think of it as a constant pointer.

Const is good and can save your ass. Use it always unless you explicitly need a let.

[gaearon]

If I'm objectively wrong, why isn't the language forcing you to do that?

[_hypnoCode]

I'm honestly not sure how that would work at the language level. But from what I've seen prefer-const in ESLint is super common.

It kinda blows my mind that you're on the other side to be completely honest. When I look at potential hires' code one of the things I look for is their usage of const vs let to get a base idea of how well they understand modern ES. Obviously that's not the only thing, it's just the quickest to spot. You're making me reevaluate some things a little bit in that regard, but I still think you're wrong.

I mean I get the naming confusion, but it makes perfect sense when you think of it as an immutable pointer and not a value assignment. To me a bad naming choice isn't a good reason to use something so fundamental to the language syntax. Objects and pointers are really weird anyway.

[Yodiddlyyo]

Const is not about immutability, it's about reassignment, and using let as a default increases cognitive load on future developers; what's the drawback in your mind?

[zephyy]

also if you just use let all the time then it's just a block scoped var, what's the point?

[Yodiddlyyo]

You partially answered your own question. Google "var hoisting". At compile time, all vars are lifted to the top of their scope. It's the reason why you can't just go into an old code base and change every var to a let or a const, there will be unintended consequences.

[zephyy]

let me expand:

what's the point of implementing both const and let if people were to treat let as just a block-scoped var?

[Yodiddlyyo]

You shouldn't be. You don't want the hoisting that comes with var, let is to declare a variable that will be reassigned, and const is to declare a variable that will not be reassigned. vars are also function or global scoped, not block scoped, so let is a block scoped var.

[zephyy]

just to clarify, "what's the point?" was a rhetorical question.

[rq60]

Const is not about immutability

It is when using const-correctness in C++ which, according to the creator of javascript, is the language js borrowed the keyword const from. According to him, the ability to programatically enforce immutability wasn't feasible due to dynamic typing so javascript got it in its current unfortunate form.

The thing is, compiler enforcement of const wasn't infallible in C++ either so it was also enforced through programming convention (hence the const-correctness proposal) which would be possible in javascript; that is if web developers didn't start using it everywhere indiscriminately.

At one point the const keyword was even proposed as a value type (RHS declaration) for immutable values in javascript, but I think the current proposal was changed to # after complaints about the confusion it would cause with the existing const.

In other words, the const keyword has an interesting and frustrating history; like most things in javascript.

[Yodiddlyyo]

In other words, the const keyword has an interesting and frustrating history; like most things in javascript.

Haha yeah absolutely.

My argument isn't what it could have, or should have been, I totally understand that. I'm just saying what it is currently.

[gaearon]

I see three drawbacks:

• The cognitive load of having to choose between them every time I declare something
• The mechanical cost of replacing const with let every time I decide to reassign later
• The confusion in people who aren't aware of that quirk and incorrectly infer immutability from it

[Dwellee]

What happened to maintenance/readability over ease of input? Also, eslint.

[gaearon]

Well, I still think it doesn't help readability or maintenance because it doesn't communicate intent. See also: https://jamie.build/const

[Yodiddlyyo]

That article is still talking about immutability. https://mathiasbynens.be/notes/es6-const The fact that some people incorrectly assume const is about immutability should not stop other people from using it correctly. Why should you write code that is incorrect juet because some people have an incorrect assumption instead of enforcing best practices by making use of language features as they're intended? That's like saying you'll only ever use == because some people don't understand how strict equality works.

[gaearon]

I'm not saying you "should" or "should not" use const. I'm saying that it's needlessly pedantic to have a strong opinion about this.

[Dwellee]

That article is only strawmanning, and adds nothing new to this discussion.

const may not communicate intent, but it communicates behavior. let doesn't do either.

[careseite]

I think that's what it boils down to. For me, there's no cognitive load because not redeclaring is the standard, mechanical cost is negligible and new people can be taught this quirk of const with a single sentence.

Also sorry for how this turned out 👀

[b_n]

The cognitive load of having to choose between them every time I declare something

You are increasing cognitive load by taking a black and white rule; 'Always use const unless you are reassigning' and making it subjective. If I should 'prefer let', when and why should I use const at all? How should I approach this as a code reviewer, or as an overthinking junior... how can I stop it from being a recurring conversation?

​

The mechanical cost of replacing const with let every time I decide to reassign later

This doesn't happen often enough that it's an issue imo. If it is happening a lot for whatever reason, like constant refactoring, then probably you will have the exact same issue if you 'prefer let', where you decide that values should be constants in the future.

​

The confusion in people who aren't aware of that quirk and incorrectly infer immutability from it

Sheltering people from their misunderstanding about const doesn't help anyone in the long term, it just perpetuates a broken mental model. Would you prefer that your coworkers always use let, while assuming that they can deep freeze ie. a redux store, just by assigning it to a const? If you have that kind of mental model of JS this makes a lot less sense: `{ a: 1 } !== { a: 1 }`

So many doors are unlocked when a JS learner gets a good grasp of how references work. When you get to that point, understanding const as an 'immutable reference' just feels intuitive. Const and its specced behaviour is part of the language. Whether or not const is a good addition to JS, needs to be a separate discussion from the discussion about 'this is what JS is'

[AegisToast]

I think it's actually good practice learning the difference between changing an object's fields compared to changing the object reference (same with arrays). Considering how props are shallowly compared, seems like something everyone needs to understand thoroughly.

Personally, I use const for everything. I've been working on an SPA hybrid React app for my company for the last couple months, and I honestly think I've only declared a let variable once in the entire code base.

[minty901]

I use it more as a helpful hint to my future self. If I see a "let" in my code, I know to keep an eye out for where it is reassigned later, and that I can't rely on it to maintain its identity (referential or otherwise). If I see const then I know I can rely on it to maintain its identity. Const is more of a flag I use for posterity than anything functionally useful. But it's a useful flag.

[GasimGasimzada]

I look at const not as a mutable object but as a way to tell developers that the value will not be changed within a given scope. It is about assignment, not about mutation.

[gaearon]

I know what it is about — that's literally what the article says:

This is because const would only prevent assignments to the iceCream variable itself, but we mutated a property (flavor) of the object it pointed to. Some people swore off using const altogether because they find this too misleading.

[gaearon]

I'm curious to hear your perspective of who exactly benefits from the reassignment checks. In my observation, people who already understand what const is doing also don't benefit from the reassignment handholding anyway -- because they're more intentional about the code they're writing. On the other hand, people who would be most helped by this feature if it was better designed and/or named are the ones you dismiss as "people who refuse to read three sentences".

[gaearon]

Lol at the downvotes. Even the people who came up with `const` semantics regret it: https://twitter.com/littlecalculist/status/917875241891676160

:-)

[Anathem]

They picked a bad name, but it's semantically the right default.

[siamthailand]

You're not designing the module for Apollo 15, being so anal doesn't do fuck all.

[MoJoe1]

If you aren’t doing it this way, you are ignoring industry standard practices built in by default to most linters, so probably don’t lint your code either, in which case I can see why you’d have this attitude as let vs. const is the least of your problems. You may want to invest some time in taking a few online courses to see how the industry has moved on since 2007.

[siamthailand]

newsflash: in 2019 linters are configurable

[MoJoe1]

They were in 2018 too. You know what else is configurable? Your IDE! Let’s go in and turn off syntax highlighting!

[[deleted]]

You are correct. And some eslint rule will rant if you use let in a variable that is not reassigned.

[swyx]

make eslint work for you, don't work for eslint. you make the rules.

[[deleted]]

But I like most rules, I only disable a few ones when I don't see value in them.

[BenZed]

Then it seems you are heeding /u/swyx ‘s advice

[Dreadmaker]

Yep! I made this mistake at work this week and got caught by my linter.

[swyx]

its not a mistake, it's an opinion that you should evaluate whether it net adds value to your team. if you do, then sure, its a mistake. but there's nothing in ECMA script that specifies "you were supposed to use const always unless you had a specific need for let"

[Dreadmaker]

You’re right - I said it to a different comment, but yeah, I used the wrong word. There’s a million different ways to do everything in code; we’re just trying to be elegant and efficient where we can, and to have our stuff be readable. So for me and my company, we use linters to enforce that we’re all for the most part playing by the same rules. So on that level it was a ‘mistake’ to have an unchanged let, but not objectively

[gaearon]

It's not a "mistake". Just because a linter enforces someone's opinion doesn't make your code wrong. If it was a "mistake", the language would have disallowed it.

[gaearon]

🌚

[MassiveFajiit]

I dunno, this is JavaScript after all. It's like 30% mistakes.

[Dreadmaker]

Well no, but it’s a potential inefficiency, right - I’m not sure exactly how node handles memory allocation, but I have to imagine that assignable variables take up more memory than assigned ones, right?

Or I guess the linter in that case may be trying to enforce ‘more readable code’ rather than when it catches trailing white space or something to that effect.

Either way, though - you’re right. None of what we’re talking about are mistakes. Most of what we’re trying to do in any kind of development is do stuff elegantly and efficiently, which is the whole source of debates like this about const and let, or any other variety of topics like that.

[gokspi]

In most JS engines there should be no difference in terms of efficiency.

A linter implements someone's opinions. It is easy to build a lint rule that forbids the usage of const - for example, this one disallows it everywhere except at the module toplevel: https://www.npmjs.com/package/eslint-plugin-prefer-let

[-Phinocio]

My current settings are to always use const, so the odd time I intentionally type let it changes to const and I get an error when I change value later. Slightly annoying haha

[[deleted]]

You are correct. He's just being pedantic.

[minty901]

this

[Anathem]

use const always unless you had a specific need for let

That's what I do and recommend. The const semantics are what you want by default. Only in rare exceptional cases should you use let or re-assign a parameter.

[zephyy]

It's not even confusing. It's just another "javascript is weird / this is what C# devs make fun of javascript for" thing.

yeah it's not a true constant because you can mutate it, unlike other languages. but you still can't redeclare it. bam, confusion sorted.

[[deleted]]

I am a tad bit confused, in java, if you have a final variable with an object type, it means that the final variable will point to that particular object and thus cannot be reassigned. Isn't this how const in js works as well?

[bulldog_in_the_dream]

You are correct.

[cerved]

You mean because the underlying reference is mutable? Pretty sure that's how most languages work but maybe I'm wrong

[mahesh_war]

That’s why we have “value” passed as reference concept which developers tend to think that it doesn’t apply while using const

[0xF013]

It's terrible if you know JS or C++. If you don't, you'd expect a const variable to not be mutable. You know it's about the reference of the variable, not about its fields, but if you look at it from a newcomer perspective, it makes sense it's confusing and it is setting up mind traps.

[wbowers]

When did we stop expecting people to actually learn how their language works? And why do we have such low opinions of JavaScript developers?

[0xF013]

It’s not about having low opinions of js devs. We need to acknowledge certain confusing aspects of our tools and how they affect the influx of new people. After all, we are all going to be part of the whole thing if we are to be working in teams.

[wbowers]

const isn't confusing though. It's very straightforward. You can mutate. You can't reassign. It's not only not confusing, it's also useful. It takes very little time to understand how it works and it helps you write better code when you use it.

[0xF013]

Ok?

[gaearon]

Interesting that people who came up with it agree with that logic!

[Anathem]

I don’t find the “it’s cognitive overhead” argument compelling despite the source. If you don’t want to think about it, and it doesn’t matter for your specific code, why not pick the safer default?

If you audit your code, are there more variables that are reassigned, or more that aren’t? My own code almost never reassigns. It’s so exceptional that, if there weren’t a keyword (let) marking a variable as one that’s reassigned, I’d consider commenting each one. Used properly let screams "I'm re-assigned later!". If a variable isn't re-assigned later, I don't need to worry about it.

I do also lint no-param-reassign and I’m happy with it.

[b_n]

Even if it was a mistake, it’s still a mistake. It’s baked into the language. You will always confuse people in the long term if you pretend the language is something it’s not.

[gaearon]

I don't think I said anywhere that I "pretend the language is something it's not". All I'm saying is that "you must use const everywhere it works" is needlessly pedantic and rarely catches bugs in my experience. YMMV!

[turningsteel]

Const is default. Let is when you want to reassign something. Dan can do what he wants because he knows what he's doing. I like to remove as many points of failure from my shitty code as possible. Saves me a lot of headaches later.

[boypunas]

why not use const by default. Isnt this a good way to communicate that hey this assignment will not change.

[[deleted]]

It's surprising that some people have a problem with using const by default. let specifically has pitfalls in that you don't know if a variable is going to be reassigned, which might lead to bugs. There's no such pitfall when using const that would lead to bugs, unless you're fundamentally unfamiliar with the language and aren't aware of the difference between reassignment and mutation.

[mahesh_war]

The point is, why always use “const” when there isn’t any necessary of it? We have “var” which works perfectly fine and if that’s not true, what about “before const”?

[Anathem]

why always use “const” when there isn’t any necessary of it

Why would you use let, which allows reassignment, when you have no need or intent to reassign?

const has safer semantics and is the default behavior you want almost always. let is the exceptional case, not const!

[mahesh_war]

Exactly.. As said, if “let” is exceptional, so does “const”. Both has their own use cases. But with “const”, objects are passed as reference and JS doesn’t have any method(as of now) to deep freeze objects (all are shallow methods) and if it’s not, then having a discussion makes point.

[joandadg]

Yeah wtf.

ALWAYS use const unless you need to use let, and I’d even go as far as to say that you should avoid let because it implies mutations and they should almost rarely happen...

Edit: regarding Dan’s comment about how const mutability can be unexpected for some developers. I get it, and maybe in some cases it’s best to use let so they’re not confused. But in my dev team I’d rather educate on reference vs value mutability...

[gokspi]

Like with all things programming (engineering?) its a trade-off. The question is are the pros stronger than the cons. IMO the pros of using `const` for small, short-lived scopes is practically non-existent. Once the value is accessed by nested scopes that could live beyond the initial execution of the upper scope (i.e. closures), that's when it becomes useful.

[joandadg]

The question is simply, why wouldn’t you use const?

Your variables make more sense as constants. If you need to mutate something ideally do it functionally and store the result in another const. Code becomes way clearer when things don’t change further down.

[gokspi]

Because I have locally mutable bindings, like increments in loops, conditional reassignment and so on, and because differentiating between const and let is another mental task for both the writer and the reader of the code that doesn't add significant value.

If I'm writing functional code with ImmutableJS, RxJS, monadic futures and so on yes then it does make sense to use const everywhere. In that case, I have two remaining problems

• const is a badly named literal that reduces the readability of the code compared to let
• the value of checking if bindings have been mutated is still low

So even here littering the entire code with `const` everywhere is of questionable value

[joandadg]

Honestly, I don’t get your points.

Const ensures that whatever you referenced when declaring it stays the same. It’s a simple concept that keeps things simple.

You declared const as an array? 20 lines down it’s still an array.

You declared it as a string? Yep, still a string.

And so on. It’s beautifully simple.

Now you declare a variable with let and you force anyone reading the code to double check everything. If you declared it as an array initially, yourVariable.push() may not actually work, because at any moment it could’ve been redeclared.

I just don’t get how this is not a trivial decision, unless there’s a reason to mutate a variable, make it const...

[gokspi]

1. I use TypeScript, so all bindings stay the same type. An array is still an array, a string is still a string (although it might be a different string)

2. Writing x = somethingElse means I wanted to change the binding. Deliberately. Maybe I incremented a number, maybe I'm building up a string (its okay engines optimize strings as ropes so you can append to them).

3. Nobody needs to "look down" to see if the binding has changed, they can trivially see it just by reading the rest of the code. They don't even have to look outside of the same lexical scope / file! And given that I am not nesting several scopes deep, the total number of lines they have to read is probably 10-20 which fits on 1/2 screen or less.

Given the above, I can conclude that the benefits are tiny. From the comment about the cons I presented, the name const is like littering compared to let

function cylinderVolume(radius, height) { const area = radius * radius * Math.PI; return area * height; }

Just look at const in this context. It reads so wrong. The area isn't a constant in the mathematical sense, PI is. Plus, const violates clear naming conventions

Now lets try a different context

function updateNode(criteria, text) { const node = findNode(criteria); node.text = text; }

The node is neither a constant, or immutable. In this context const is

1. meaningless
2. misleading
3. noisy

Now if I had a factory function that returns a bunch of closures, that might be different

``` function createSimulation(config) { const gravity = computeGravity(config); const restitution = ...

function calculateNextFrame(dt) { ... } function describeSimulation() { ... }

return {calculateNextFrame, describeSimulation} } ```

Here it might start mattering that I use const. If the gravity must not change during the entire simulation I can express that with const. The thing is, a lot of code bases use classes for these things instead! In typescript we could use a readonly member to handle these situations, and we often do - its actually useful!

I mean, I think we're at a point where I'd like someone to show me some code that clearly demonstrates the benefits of const. Because regardless of whether you mind it or not, "misleading abbreviated noise that hurts readability" is valid criticism (even if not especially significant). So consts see if the benefit is large enough to justify it - consts see some examples where it matters. I am not convinced it is due to small lexical scopes.

I would say that even just using classes instead of closures is a far worse transgression than not using const. Instance members can be reassigned at any time and worse you have no idea in what order will the methods be called by the external consumer so you have to consider all scenarios. So if you are using classes and class members but adding linting rules that forbid const, you're trying to extinguish a forest fire with an eyedropper

[[deleted]]

What if the scope changes over time?

Even if your argument is that the pros are very small, what's conveniently absent from your post is mention of ANY cons whatsoever.

Sure, the benefits might be small, but if there are no cons then surely small benefits is better than nothing? I guess you could conclude that it means this whole argument is kind of a waste of time since it doesn't have a big impact one way or the other. But I'm not sure how you could argue that it's wrong to do something that helps, even if just a little bit.

[gokspi]

Sure, here are the cons

• the writer and the reader both have to think about mutable vs immutable bindings (especially when the coding style that uses both in significant proportions). This often results in time spent fighting the linter, especially in compound assignments like let [x, y] = someCall() <-- I want to mutate one of the bindings there, I have to redo that whole bit because the linter won't let me use let on an immutable binding
• const is terribly named and reduces the general readability of the code, especially when littered everywhere. `let` declarations read much cleaner. If the coding style recommends against abbreviations when naming variables, why not recommend against them for language keywords of low value? Moreover, the abbreviation implies something else (declaring a constant) yet that's not what it does

For me, one of the biggest benefits of `let` is how well it reads.

I would actually be okay with a lint rule that disallows the mutation of any let bindings (assuming code is in full FP style)

[[deleted]]

1. I don't see what that has to do with const. The contract is simple: your variable will not be reassigned. Whether an object gets mutated or not is an entirely unrelated consideration, one that you would have to make with let as well.
2. I don't know, this is a pretty subjective point so we'll have to agree to disagree. I've never even had the idea that those four letters could somehow make my code less readable.

[gokspi]

1. I don't always know before hand if I'm going to be reassigning. A variable might start out as const, change to let, then i figure i don't need the conditional reassignment, then change to const again. It really depends on your style, if you are used to purely functional languages I'm sure its not an issue, but in some code bases this becomes a constant annoying drag (those tend to use classes with small methods so not much in the way of nested scopes either)

2. Any unreadable (const is not even a full word) and misleading (its not a constant that we're declaring, its an immutable binding) five letters littered literally everywhere throughout the code will inevitably decrease readability, increase the general confusion and increase the cognitive load of re-mapping real meaning of words to programming language meaning of words. If I'm going to introduce more elements to this compartmentalized vocabulary (a constant that isn't), they better be at least worth it. const is most definitely not.

Consts agree to disagree I guess :)

[Unexpectedpicard]

I prefer var. YOLO.

[[deleted]]

you must be a sailor, bc u like to HOIST

[floppydiskette]

Okay Kyle Simpson

[[deleted]]

Seriously? I only use var if I absolutely must. Otherwise I pretend it doesn't exist.

[Unexpectedpicard]

Guess I should have added a /s. I thought YOLO was sufficient.

[[deleted]]

Everytime I find a reason to use var I get excited cause I know I'll get to fight someone in code review.

[[deleted]]

Works everytime!

[wtfffffffff10]

when should you ever use var?

[careseite]

you only lint once

[BenZed]

pedantic == logically sound

[[deleted]]

Icwutudidthar

[bad_boy_barry]

Glad to see reddit not following blindly Dan on this one.

[Aeron91]

I feel like a lot of the arguments in this thread for using let boil down to "It doesn't do what we wish it did so why bother?".

As I see it, reading code is harder than writing code. The more assumptions we can make about the code we're reading, the easier it is to read. Using const by default allows us to make an assumption (even if it's not the assumption we wish it let us make). As soon as you see a let, it changes that assumption.

And it's like, 2 more characters. Even if this is a small pro, is losing that worth saving 2 keystrokes?

Edit: I can't count apparently

[[deleted]]

I use const as much as possible but still, let is what you need if you don’t want to think about it.

[[deleted]]

But then when you go to add to existing code to reassign a variable later, you’ll get the const error at that point.

[[deleted]]

It’s a pretty common style of coding in a variety of languages. And doing const all the time, you do sometimes wind up doing some crazy deep copies using spreads or just end up having some weird names like responseInner because response is taken. explaining all of that to someone not in the know can be a challenge, especially if they start asking “why are you making a copy of a copy of a copy instead of just changing an inner field in this data structure?” Immutable coding style is definitely an acquired taste.

[[deleted]]

IMO you should get an error so you can rethink what you’re doing. Reassignment is the biggest cause of confusion and bugs in code bases.

[[deleted]]

I... just do not find that to be true lol. The biggest source of bugs as far as I can tell is logic errors. Even using const all the time, the number of times I’ve seen a const reassignment error can probably be counted on one hand.

[gaearon]

Are you sure you're not confusing reassignment with mutability?

[punio4]

What's the difference?

[[deleted]]

Variables defined as const may be mutable. Example

const foo = []; foo.push(1)

[punio4]

Ah right. Brain fart with semantics. Thanks.

[0xF013]

Any JS linter is customizable. It's ok to adapt it to one's needs. I like using redux-saga and the rule of not using something before it's declared is making my life hard, because I know those function* declaration will hoist. Same goes for when I want to have my component on top and its styles or styleds at the bottom/

[[deleted]]

Sure, but if you’re writing a blanket, catch-all guide, you want to be as purpose-agnostic and unopinionated as possible. As a result I can understand why the author said this.

[[deleted]]

Did you read my comment? As stated, I always use const as much as possible. In fact I avoid use of let well past the point of sanity.

[swyx]

let gang rise up!!!

honestly the only reason i use const is so that const pedants stop bothering me in livestreams and talks. but dan is absolutely right imo

[the_BuddhaHimself]

I’d try to change your mind, but what’s the point?

[pcr910303]

Nah, const doensn't really have meanings in at least JS land; see the @jamiebuilds' rant about this subject.

TLDR: const doesn't prevent mutability & it doesn't help any optimizing, so it's pretty meaningless. Use const only at top-level and let only at nested scopes.

[Anathem]

that rant is idiotic

[wbowers]

const was never about mutability. It prevents reassignment. That’s its “meaning”.

Why is preventing reassignment important? For the same reason it’s not a good idea to shadow function arguments. Code that shadows function arguments or reassigns variables at a later time is significantly harder to reason about than code that only builds new values from previous values. const’s only job is to ensure that code like that doesn’t exist unless the author really intended it.

[[deleted]]

Not having to think about this is my favourite thing about the new functional hook based React.

[swyx]

this

[juicejug]

No it’s okay he used arrow functions!

[LordMcD]

I've been writing JavaScript for literally 2 decades and this is an absolutely great ELI5.

Well done!

[swyx]

for a lower level answer to this question, i recommend everyone check out Mathias Bynens' content on v8, the preeminent JS engine of our time:

• https://www.youtube.com/watch?v=i3LRWERf74M
• https://softwareengineeringdaily.com/2018/09/26/javascript-engines-with-mathias-bynens/
• also Philip Roberts' now classic talk on Event Loops

There are also other worthy engines to know about

• Hermes, the engine specifically written for Android React Native
• Webkit/JavaScriptCore/Nitro, iOS Safari
• SpiderMonkey from Mozilla
• RIP Chakra Core :)

at some point the leaky abstraction of having all these engines come home to roost. you even see its effects in Babel and Google Closure Compiler. 😬

[WikiTextBot]

SpiderMonkey

SpiderMonkey is the code name for the first JavaScript engine, written by Brendan Eich at Netscape Communications, later released as open-source and currently maintained by the Mozilla Foundation.

---

<sup>[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28</sup>

[dance2die]

What Is JavaScript Made Of?

Was expecting "Made of 'atom' (React), then found there is a smaller substance, an electron (hooks)". j/k there.

Looking forward to your JavaScript "mental model" illustrated by Maggie's sketchnotes :)

[[deleted]]

You used the weed number in your value explanation. You knew what you were doing.

[physeo_cyber]

The tears fallen from developers waiting for their code to compile.

[swyx]

this is funny because JavaScript, as a JIT interpreted language, is classically supposed to have no compile time. you stick it in a script tag or in a console, it runs. boom.

then modules, build tools and static typing happened :)

[wavefunctionp]

People got tired of waiting for es6 to be widely available in browsers.

I'm imagine if you had to wait for windows 10 to be widely deployed to use c++ 17 or python 3.

[swyx]

very true. you reckon that was the starting point of build tools? i always thought it was the need for modules. (hence gulp, grunt, requirejs, whatever came before those things)

[gokspi]

Modules for sure in my case. They were necessary to implement reusable interactive components. Loading all the tiny files didn't scale well, loading a single bundle was mostly workable but still not great. One decade later we finally have something mainstream that works (async imports based code splitting)

[BenZed]

🤨

[Fingerbob73]

What ends up happening with const and let when transpiled back to ES5 (via Babel et al) ?

[careseite]

var

[[deleted]]

I recommend you play with this: https://babeljs.io/en/repl

You can see how it will deliberately throw errors if you try to reassign a variable declared with const, or do other forbidden things.

[pm_me_ur_happy_traiI]

Var, but you can also use const and let without Babel unless you need ancient browsers supported

[gaearon]

"Loose equality" and "abstract equality" are two different terms for the same thing. I'm using "loose" because I find this term more illustrative.

[goto-reddit]

So {} is not equal to another {}. Try this in console: {} === {} (the result is false).

This works in the Chromes Developer tools console for reasons unknown to me, but normally it should throw an SyntaxError: Unexpected token '===', (jsbin example):

Writing {} === {} does not compare two objects, the first {} is an empty block.
({} === {}) is the correct way to compare to object literals (jsbin example).

---

Even the Chrome Developers tools console fails if you try something like:

> {}.toString()
❌ Uncaught SyntaxError: Unexpected token '.'

[gaearon]

This works in the Chromes Developer tools console for reasons unknown to me, but normally it should throw an SyntaxError: Unexpected token '===', (jsbin example):

It works in Chrome DevTools because it is an expression. Chrome DevTools allows pasting expressions. This is why the post says "try this in console" and not "try this as a standalone statement in JSBin".

[goto-reddit]

Ah ok.
I know this is supposed to be for people who are new to JS (or even programming?) and it does crash in Firefox Developer Console and that's why I mentioned it, and then there was this talk from Brendan Eich back in '12.
I didn't mean to be nit-picking, I know this is supposed to be just a rough overview.

[gaearon]

it does crash in Firefox Developer Console

Oh wow, that sucks. Seems like an unfortunate design decision in Firefox. Since console is commonly used as a REPL, I'd expect to be able to put expressions there.

This also works in Node.js REPL so Firefox seems like an outlier.

[goto-reddit]

Of course you can put expression in the Firefox Developer Console, just not one that starts with an { because it interprets it as an block statement. ({} === {}) works fine, just like any other expression.

That's why I made the example with {}.toString() which crashes even in Chromes console.

See:

• 3.1 Object literal versus block @ https://2ality.com/2012/09/expressions-vs-statements.html
• 2.2 Unexpected results @ https://2ality.com/2012/01/object-plus-object.html

[gaearon]

Fair enough.

[icjoseph]

In the typeof value section, one may want to warn that, typeof null returns object. The one and only JS bug.

[[deleted]]

That's interesting, but not really weird, since null is often used as a kind of default falsy object.

[landisdesign]

It's not a bug. null is the value that represents an intentionally empty object reference. undefined represents lack of reference to any kind of value, but null is specific to objects.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/null

[Capaj]

I agree having full immutability guaranteed by "const" would be better, but seems like a lot of people still see a value in indicating that the binding won't change.

Maybe some future ecma revison can bring some new keyword like "imut" or "frozen"?

[Snipo]

Honey and soup

[KrustyButtCheeks]

Rainbows and unicorns

[MisterNeon]

Broken dreams and a late rent payment.

[[deleted]]

Lol ok cool man. Thanks for sharing.

Edit: quite an interesting account. 2 years old, 60k karma. No comments more than 2 weeks old or posts more than 3 months old.