No const! How NOT To Give A JavaScript Talk

[@traviswatson6527]

I can see Ryan's point that using `const` by itself doesn't matter. However, `const` shines because using it by default makes `let` stick out like a sore thumb. It's an extremely valuable visual hint that "this is doing something unusual, pay more attention to it". If you use `let` everywhere, you lose that "here be dragons" helper.

[@WillyGrippo]

Very well said

[@mryechkin]

Yep, agreed 💯

[@quadrumane]

100% this. I always use const until I need let. And that makes my intent more explicit in my code when something is intended to be reassigned. I still use const + SCREAMING_CASE for actual constants. Most importantly, when I talk about the code, I refer to const CONSTs as 'constants' and const + let as 'variables', regardless of what the ES6 name is. I don't call variables 'lets' for example. Not sure why Ryan can't distinguish between what they do and what JS uses for declaration names. Pythonistas still remember to call them variables even without any var/let/const/int..

[@avidworkslol]

It's a good point, but for some reason we've flipped "if everything is important nothing is" on its head for the sake of "not accidentally mutating variables". Should it not be const for the important stuff and let for everything else?

[@aivisabele]

Totally agree.

[@abcq1]

I like how fluently and, seemingly, without any effort you keep yourself from calling that talk a total bullshit under the blue moon, which it definitely is. Respect :)

[@jherr]

I'm not here to do that honestly. I just want to teach folks how to do web stuff. This video is way outside my wheelhouse. I only covered it because enough folks were taking it seriously that I had to say something. If the video were marked as parody up front I wouldn't have said anything. Though as parody goes it didn't really do it for me either.

[@SteinGauslaaStrindhaug]

@@jherr Yeah, I watched the original, and to me it screams parody/joke lecture. I'm pretty sure his only actual point is he prefers to reserve the "const" keyword for constants and not use it for variables that happens to not be reassigned (which is a valid preference, though I have the opposite preference) and the rest of the "arguments" were just joke arguments probably delivered too deadpan for everyone to notice. It feels like neurodivergent humor, we often enjoy making up silly arguments to justify a preference which really is just a preference. When you have years of experience in programming, you realise that most "rules" in programming is just preferences so this lecture would be an obvious joke for most veterans, and judging by the laughter I assume most of the live audience were experienced programmers who correctly interpreted it as a joke lecture too (it feels like a slightly off topic, lighthearted lecture that is often scheduled last at a conference as entertainment after a long day of hard topics); but either he or whoever uploaded it to the internet forgot that it might not read as such an obvious joke to a general audience when removed from the context.

[@bigk9000]

I've seen other developers, smart developers, use let instead of const when they should have used the former, and as over thinking and analytical as I am, I always wondered why they'd do it that way. While I never got an actual answer, I think it was just because it's easier and very slightly quicker to type for some people, being one character shorter. But even then, it's just a guess. Now, I could maybe see an argument if it causes an issue with memory usage or garbage collection, but, again, that's just a theory. As for me, I use it everywhere. I only use let if I absolutely need it.

[@EduardKaresli]

Coming previously from the world of C++, const is perfectly fine to me. When declaring primitive type values as const, then they are constants. End of story. When declaring a value of a complex type to be const, then I understand it as "the reference to the content in memory for this object is const", that is "the room number is const, the contents of the room itself are not". Again, no problem with that either.

[@keithjohnson6510]

Totally agree, it's like "int* const i = &x;" IOW: 'i` itself cannot be re-assigned, but what `i` is pointing at `x` can. *i = 42 In this sense it's no different to how JS handles Objects, objects in JS are implicitly pointer types, it's just more automatic.

[@mackenziesalisbury5406]

Note that values of complex types can indeed be const, not only pointers e.g. const Dog fido; You can also have const pointers as you describe, or pointers to const (where the pointed-to type can either be const or not)

[@Datamike]

This is what I was thinking too. The whole talk is basically just another medium article with a title "Stop using / doing X" and you just know because all reasoning is suspiciously absent. If you think you complex types aren't constants, declare an array and try to change it to a primitive. I guarantee you it won't work.

[@darkferiousity]

coming from c++ too most useful thing I foumd about them is when passing in an array to a function and setting it to const if it is meant to be read only ensuring the contents are not changed by the function. I guess this is different in javascript as the address is unaltered but the contents of the array can be changed by the function.

[@gownerjones]

And the root type is constant as well. A let variable can change from any complex type into any other type at any point. Consts stay their assigned type forever.

[@DMC888]

I don’t see the problem with const = array[]. It’s a pointer to an array, that pointer never changes.

[@mistymu8154]

It would be preferable though if a const array contents were immutable though.

[@taragnor]

Yeah in JS I'd say it's a good practice to use const only for an array you don't want to change. While JS will allow you to alter the object, it can get confusing given JS doesn't have an explicit distinction between pointers and the objects they point to being const in the way that C does.

[@recursiv]

@@mistymu8154 Why? const indicates that the identifier binding never changes. It means nothing about mutability. I use const for values I intend to mutate all the time. I have yet to hear an argument about why this is bad. const is for binding, freeze is for immutability.

[@Beakerbite]

@@mistymu8154 This is how it is in every language though. The const signifies that the reference won't change. If you want an immutable data type, then you use an immutable data type. You'll notice he didn't use any examples with strings because they are immutable.

[@luukberkers9361]

Not in Rust. In Rust you can only use .push on a Vec that is mutable

[@GrumpyGrebo]

ChatGPT also spelled "their" wrong in its response... I think we can all take that accident to its logical conclusion.

[@JohnyMorte]

touché

[@bertilorickardspelar]

Yes and relying on ChatGPT for that kind of advice is probably unwise anyway. ChatGPT can answer tons of questions about it's training data and even extrapolate from there. But to assume that the training data is mostly correct is quite a leap. Collect information, form your own opinions.

[@GrumpyGrebo]

@bertilorickardspelar ChatGPT is a tool, but it states possibilities with certainty. Same as most other LLMs. It can hallucinate... ask it to write you some Javascript to make a request to AWS S3 that will make you cheese on toast. It will do it. Used as a tool, it can be great to turn words into structure. If you are stuck on loops within loops and struggling to turn your verbalisation/pseudo into actual, it can be very useful.

[@grahampcharles]

@@bertilorickardspelarI think you missed the point of what the misspelling implies.

[@bertilorickardspelar]

@@grahampcharles I assumed it meant that it was written by a human and not AI. I think the lecturer tried to fool the audience that his point was valid because an AI agreed with him which it did not. I agree with Jack. Const is not a magic bullet but it will not ruin your code either. The biggest danger with AI is trusting it too much.

[@VeitLehmann]

I'm in the const camp as well. And I like using linting rules which push for const if no reassignment happens. This way, seeing a let is an indicator for me that there is reassignment to watch out for. As of arrays/objects defined via const: We all know that const doesn't prevent their content to change. But at least they will remain the same type. It's the same with TypeScript in general: You don't get 100% type safety, but you get at least some level of security. His argument would render TS irrelevant because you can't be sure if there is any any in the code, so "just stick with JS"

[@joelv4495]

I've been learning go recently because I'm tired of TS fake type safety.

[@Veretax]

I keep going back and forth on this to be honest. I've gotten into a habbit of just writing const, and then letting eslint catch when its being changed to then change it to let. But I do find that the scoping parts of javascript sometims make me wonder why we put so much inside a given function.

[@tantalus_complex]

​@@VeretaxCould you expand on your last sentence?

[@coadyx]

In JavaScript, using const indicates that the variable will not be reassigned, meaning you're always working with the same object. This is incredibly helpful as it eliminates the need to scan the entire source file or function to check if the object has been reassigned. Remember, you can declare an object with const in a function, mutate it, and return it-the function is still pure because the function isn't mutating data outside the scope of the function. Additionally, mutating an object can be faster than attempting to destructure it into an entirely new object with new memory allocations.

[@astronavigatorpirx26]

>> "In JavaScript, using const indicates that the variable will not be reassigned" >>" always working with the same object" Actually it is not. It can be reassigned. But it cannot be directly reassigned. It will be reassigned many times if you use it inside a for-loop. And yes, it also can hold different objects (or even can hold both objects and other types): for (const obj of [{}, {}, {}, 123, "my string", new Date]) {console.log(obj)}

[@gownerjones]

@@astronavigatorpirx26 When you're using it inside a for...of loop, you don't reassign, you re-declare the constant and then assign a new value to a completely new constant in memory.

[@astronavigatorpirx26]

​@@gownerjones What about using let in cycles then? Do I declare a new variable every iteration? Like in for (let x=0; x

[@gownerjones]

@@astronavigatorpirx26 I'm sorry, I don't know what you want me to tell you. When you use a for..of loop in Javascript, every iteration creates a new instance of that variable or constant. It doesn't matter if you use const, let or even var in this case. All you need to do is type into Google "js why can you use const in a loop" and you'll find this answer readily. It's also described in the official docs in the for..of article: "You can use const to declare the variable as long as it's not reassigned within the loop body (it can change between iterations, because those are two separate variables)." And later: "Note: Each iteration creates a new variable. Reassigning the variable inside the loop body does not affect the original value in the iterable (an array, in this case)." For...of loops do not reassign the iterating variable or constant by design. That's the reason why we can use const here but not in a normal for loop.

[@gownerjones]

@@astronavigatorpirx26 I understand the confusion I think. For loops and for..of loops work differently. You cannot declare a constant in a for loop. That's because a normal for loop will reassign the iterating variable. But when you use a for..of loop in Javascript, every iteration creates a new instance of that variable or constant. It doesn't matter if you use const, let or even var in this case. This is described in the official docs in the for..of article: "You can use const to declare the variable as long as it's not reassigned within the loop body (it can change between iterations, because those are two separate variables)." And later: "Note: Each iteration creates a new variable. Reassigning the variable inside the loop body does not affect the original value in the iterable (an array, in this case)." For...of loops do not reassign the iterating variable or constant by design. That's the reason why we can use const here but not in a normal for loop.

[@robertluong3024]

I've quit a new job (one i just joined) because we hired a new guy that removed consts everywhere and removed native map for lodash map. I asked for a justification in his PR and he yelled and screamed to the head. I gave my reasons in the PR and I don't think he thought he needed to. I realized this isn't a place I wanted to work.

[@stephenwhite7551]

yikes! replacing native maps with lodash's would've drove me nuts lol

[@ythalorossy]

You assume the risk to go to another company is a huge award for you. I see the big techs are pushing to do the same bullshit and assume it is the right way to do that. And this is why almost all the people that work for those companies never change their mindsets.

[@psychic8872]

Did anyone approve the PR? Did anyone take your position?

[@dominuskelvin]

I am convinced that the talk was a meme 🤣

[@KentCDodds-vids]

It was. I thought the fabricated ChatGPT was a dead giveaway 😆

[@dominuskelvin]

​@@KentCDodds-vids 💯and I'm sure he got us good 😅

[@JiriChara]

@@KentCDodds-vidsOops! I've already gone ahead and updated all production codebases to utilize 'let'. My bad! :(

[@KentCDodds-vids]

I mean Ryan is sincere in his preference, but he really doesn't care what other people are using and doesn't need everyone to stop using const. He really just wanted to have a place he could direct people to when they ask him why he prefers to not use const. And he did so in the light hearted way he does things.

[@jherr]

@KentCDodds-vids but then you're saying that it's not satirical. You kinda can't have it both ways. You can't say it's satire and then turn around and say that it's actually a genuine resource for his position, but if you poke holes in then hide behind satire.

[@gerkim3046]

at 8:08 , i have never seen chatgpt spell their as thier before.

[@sillvvasensei]

I saw that too. That was definitely a fake GPT response.

[@zbdad]

Good catch.

[@mike-2342]

hawkeye

[@murtadha96]

Brilliant! That’s exactly how everyone should consume information critically. Not just in tech but with regard to everything.

[@ecoded3033]

Always use const unless you need your variable to actually vary

[@b1mind]

This is how reaction content should be. Well done sir.

[@zyzlol]

JavaScript community just running out of stuff to do conf talks about at this point

[@echobucket]

The ChatGPT response on the slide has a typo. `thier` instead of `their` GPT doesn't make spelling mistakes like this. He made it up.

[@74HC138]

No he didn't. I put the same prompt into ChatGPT and got a very similar long-form response clearly advocating for the use of const. You can easily verify this yourself.

[@nightfox6738]

He was talking about the original "ChatGPT" quote the guy used to support NOT using const. Not the ChatGPT screenshots the video poster shows where he tested it himself clearly showing, exactly as you say, long form response clearly advocating for the use of const and showing the first screenshot to be complete bs.

[@lordstorm7237]

Using ChatGPT, that constantly makes up shit as a source of truth for your argument is just yikes. Imagine if that became the standard for all coding practices we rely on. "The AI told me to do it this way!"

[@amaury_permer]

We will have spaghetti code in few years, many people rely a lot in AI tools that don't even stop to read or think what the output actually is, just copy paste and done, quite disturbing in my opinion.

[@ChristofferLund]

Not to mention that the chatgpt quote was obviously faked.

[@johnpekkala6941]

@@amaury_permer So true, everyone reduced to script kiddies just copy pasting unreadable mess generated by AI. All human skill gone. I dont want that future! Sure use AI for help is ok sometimes, I do that myslef alongside Stackoverflow but I always only use it only as a template. I never downright just copy paste it into my projects as it is and certainley not without myself understanding what the code is really doing.

[@JR-jx5ym]

Yes, misspelling "their" is the last thing an LLM would do, unless you asked it to, and possibly included to indicate that portions of the talk are for entertainment purposes only

[@vytah]

​@@JR-jx5ymLLMs make grammar and spelling mistakes from time to time

[@bumbletastic]

Reminds me of the time a coworker said we should always nest ternaries and cited a Medium article to back it up.

[@acrosstundras]

Should've cited "Structure and Interpretation of Computer Programs, JavaScript Edition" book, it's full of them.

[@codefinity]

Ha! Many linter configs actually warn against doing these. :)

[@Veretax]

Ugh, I did one today, and wanted to take a shower afterward. But it lead me to encapsulate logic into two separate components rather than do it all in one place.

[@codefinity]

@@Veretax If you 💭 it should be a separate component, it probably should be!

[@Veretax]

@@codefinity I mentioned this example because it was fresh in my head I didn't set out to have separate components but then I realized I had so much different logic that would make sense to separate those different ways of rendering into two components

[@falven]

The misspelling in the "ChatGPT response", LOL.

[@cb73]

When Ryan says that AirBnB is not using their own lint rules, I don't think it's necessarily an appeal to authority fallacy. It could be in response to another appeal to authority - that you SHOULD use airbnb lint rules because they created it.

[@jherr]

You are correct, more precisely it's an anecdotal fallacy.

[@sebastianscarano9418]

@@jherr yes, I think that was the only weak point in your perfect and super clear explanation. The mention to airbnb folks not using their own stuff was to discredit the the airbnb lint rules themselves

[@jpavel]

Ryan is an awesome developer, it's needless to say it. Honestly, that talk sounded like "we need 5 min of anything to fulfill a slot in the conference". To make it more useful he could've mentioned how the typescript's `` const... as const` fixes the single case where const is misleading (not useless) he presented. In general, IMO, const makes code much easier to read.

[@ravenbergdev]

Ooh this got to be one of your best videos. To often devs take whatever reputable people say as gospel. You have guys touring the world trying to share (sell) their opinion to the industry. Sometimes they bring good insight. But likewise they can bring devs to making decisions that are costly.

[@_hugo_cruz]

Same feeling Jack, I saw that talk and I said to myself, "this can't be happening." I really don't understand the need for this. So much to talk about or contribute or at least try to want to facilitate, let's say learning. But does this man really go out with this?

[@ygeb93]

Thanks for raising this issue. There are too many conference speakers popping up who make bold statements like these. It seems like anyone can speak publicly about programming nowadays. Engineers aren't dumb and won't follow advice like this.

[@wagnermoreira786]

what a GREAT analysis!!! definitely love the critical approach, this is also the kind of thinking we need to use for code reviews

[@GiddySquire]

The original talk was indeed not very persuasive, but it did make me challenge myself to defend both points of view. The two things I like about defaulting to using `let`. * It makes object-destructuring less annoying when you destructure a property that you do not need to reassign at the same time as one that does. For example, destructuring `id` & `name` at the same time and only `name` needs to be reassigned, so `id` should be `const`. * You do not have to go up to the declaration and modify it from `const` to `let` when you need to reassign something that did not need to be reassigned before. The only thing I can use to defend defaulting to using `const`. * When using React hooks it is easier to keep people from reassigning state variables instead of calling their setters, but you still have to keep them from mutating their data. I agree with using `const` for exported variables and using freeze where needed so that I can use global constants without worrying about someone accidentally mutating them in both of the above cases.

[@jeduan]

I work at Airbnb and Ryan is blatantly lying. We 100% use const

[@aethix1986]

Do you use the Airbnb lint config?

[@tedchirvasiu]

But he said you don't use eslint, not consts.

[@bobdeadbeef]

@@tedchirvasiuBut he was using it to insinuate that Airbnb doesn't use const. My immediate reaction was that (assuming he was saying something truthful) not using that config really tells us nothing about use of const, and so maybe he misunderstood. But my real take-away is that Ryan's not to be trusted. Period. Maybe if he matures over the next decade-this isn't personal and people can grow and change-but I probably won't be around by then. In the meantime, it takes more than a spicy title to make a good talk. Unless, maybe, this was on April 1? (I still do not approve!)

[@ericmackrodt9441]

I thought that he was only talking about the eslint config.

[@astronavigatorpirx26]

I think, that actually the ability to mutate const value is a very strong argument. I use const a lot, but to be honest I always see a code smell when looking at const in cycles (where const is not const at all), and when constant object are being mutated. The REAL const is just a simple value which can be calculated one time before program started, and does not change every time you run your code (until you change your source code). For such values programmers often use UPPER CASE. like const MY_CONSTANT = 123. (I believe Ryan is talking about this case). You should always be able to replace your real constants (while building project) with real values. If not, then it's not a constant. Anyway, const keyword in javascript is still useful. Maybe it would be proper to rename it to something like "partially immutable" or "not directly re-assignable" not to confuse programmers. But it's too long, so keyword "const" for such variables is somewhat acceptable.

[@sotojared22]

Constant allows for you to mutate the data, but the object type doesn't change. It helps skip certain steps with interpretation.

[@Chiny_w_Pigulce]

ChatGPT would not make a typo in "their"...

[@AndrewErwin73]

here's an idea. if you want to store an immutable constant, use const. If you want to store a variable that will likely change, use let. The fact that this is even a question is why many programmers think javascript sux!

[@jedabero]

I was confused about the let vs const debacle. I always think like this: I'm declaring a variable for a purpose, will I ever need to change what its pointing to (reassign it)? If yes, then let's use let (maybe I'm doing a sum or an avg without a loop), if not, let's use const (I may just need a way to make sure I'm using the same reference from when I declared it). If I'm using objects or arrays and I need the content to remain the same always, then I use Object.freeze. But that has nothing to do with let or const

[@EnricoAnsaloni]

I think that some of those tech gurus' inflated egos sometimes get over their logical reasoning and they end up shouting sweeping statements like this one. There isn't even a bit of reasoning in this talk, just a statement. Personally I use const whenever I can for several reasons, the main one being the possibility of accidentally change a variable when you're not supposed to.

[@randyproctor3923]

Yeah, we’re in a STEM field. If a speaker wants to teach me something they should follow the process: state the hypothesis and tests to support, show examples, let us decide if it holds water and we want to consider it theory. You make great points in this video. He did not start with a clear message/lesson/hypothesis. His examples were not really testing the hypothesis itself, but rather picked after-the-fact to support the vague proposition. There is a word for this: pseudoscience. It’s totally fine to have an opinion, but pretty lame for a speaker to present in a way that really doesn’t hold water.

[@alyahmed7639]

Great video, I was waiting for a part which you share how typescript fixed this using as const and Readonly array

[@joshr96]

For me the only convincing argument for "let" over "const" would just be simplification. "let" would allow for one-time assignments (which I think is a good pattern to default to) and the less common case (at least in the code I write day to day) of having to re-assign multiple times within a loop. Granted you will have to enforce the "one-time" assignment via lint or compiler (which is probably better than discovering violations at runtime). I could see for a newcomer it being confusing why you would use "const" sometimes but "let" other times. Also you have to understand "const" just enforces a "one time assignment" it has nothing at all to do with immutability. But at least I'll just use "const" cause its what I have been using and what most others will understand whom I have the pleasure of coding with.

[@MrAnimus]

This makes me want to do a talk on the value of "const". I find the value of "const" is readability. If I see a function start with "const username = email.split("@")[0];" I know that the value of "username" will be the result of this expression everywhere in the function. If I see "let username = email.split("@")[0];" I need to check throughout the function to see if "username" is reassigned anywhere, and if the codebase enforces "const" where possible then I know that "username" is being reassigned somewhere. If I'm debugging an issue that involves the value of "username" this will be useful information to know.

[@jmnoob1337]

I appreciate your logical approach to analyzing these opinions! Const makes it very easy for developers to know what can and what cannot be changed. I love that it exists in the language, even if it can still be confusing with reference types for those not as familiar with the underlying workings. But even with that "strageness" around reference types, I find const to be very useful as a reminder to not try to change the particular value. And as Theo and others have pointed out, it brings a lot more meaning to `let` as well, which is a huge bonus and maybe the most important thing about `const`!

[@ShaqarudenGames]

The slide showing you can add to an array is a reason to not use const. what using const in that case does do though is ensures that that const/variable is always an array, which I would say would be a reason to use const.

[@jherr]

Exactly. Some protection is better than no protection at all. And if you use TypeScript you can get read-only behavior with no runtime overhead.

[@classawarrior]

I think there is a meaningful distinction between "happens to not be reassigned" and "is fundamentally intended not to be reassigned / other code relies on this never being reassigned". It would not be unreasonable to adopt a convention where "let" and "const" are used to distinguish between these two cases, because "const" would then convey more meaning about the intent of the code.

[@thomasr2472]

5:19 Jack, you misunderstood Yahooda's tweet. He says that const should be used for constants only. The screaming case is an additional semantic hint.

[@andrewayad]

When I read the title for the video I thought for a while that JavaScript had a hidden flaw that no body knew for all that time and the humanity figured it out just now! 😅

[@shokhbozabdullayev6260]

Totally agree that, stepping back and re-thinking is the most needed skill for the people in general and not only for developers.

[@floriankapfenberger]

In Swift let is const and var is let. Its so messy when working with multiple languages all the time. In TS I always use const, but only because of such eslint rules that yelled at me. In Swift if you use let (same as const) for an array it would not let you append so there the language is enforcing it. In JS I guess it only stops you from reassigning the variable. I actually don't have a strong opinion on those things and would switch to let if it makes more sense.

[@moathdw910]

Thanks for the video! You speak with much reason as usual that's what I liked the most, I have heard in the last few days some people repeating the same argument about const and I really was not convinced at all! I will keep using const in specific cases it's always helpful

[@ilkou]

I watched the talk before and it really felt like he’s joking but not at the same time, kinda awkward. my conclusion back then and now are the same, to keep using const unless I have to re-assign to my variable.. but I still loved listening to your critical review of the talk 👌🏼

[@kodekata]

For me, the value (hawr hawr) of const is that when I search for an assignment statement, I can immediately stop the search when I encounter a const keyword, because a const can only be assigned once. Even in loops, with const, the name takes a value exactly once. It is really useful to know and to minimize the number of times the meaning of a name changes. There are other good ideas here too, such as using Application Programming Interfaces which support the required operations. Some variables are only queried, not mutated. Who would give up a chance to politely indicate these things to the next programmer? Some techniques incur a higher cost than others. There are many tradeoffs to make, but IMHO const is worth it's weight in gold.

[@LifeLoveAndMonads]

Great video Jack! I think there are lots of opinions which people follow like rules, especially when they come from places like YT and when targeting easily affected audience. I think we need more content like this video!

[@analisamelojete1966]

Learn how to think, not what to think is a valuable skill in SE. Great video, mate.

[@LeeFloyd-lm4fq]

What I walked away with from the original talk was not "don't use it" but "don't worry about it so much". I'll use const for things I don't plan to reassign, but when refactoring old code using var it is safe to just find/replace with let and pepper in some consts when it is clear that they won't/shouldn't be reassigned.

[@CodersGyan]

Hey Jack, I also don’t agree with his points. What I have understood about const in my career is that it does not allow re-assignments. It still stands with objects and arrays. We cannot reassign their values. I am going to continue with const as well 😊 Thanks for your opinion 🙏

[@mortezatourani7772]

Also there is a typo in ChatGPT's answer '... to feel like thier code is good ...'

[@operandexpanse]

The guy presenting 100% wrote that himself. Super weird.

[@ofmouseandman1316]

Lets (!) use Vue 3 (same thing applied to react) for exemple: if you do let something = ref("") if by any mistake you do something like something = 'hey'; I wont get an error ... and will loose all further reactivity because the const does not refer to the "not mutability", but to the "reference" to the "proxy object" which you'll loose by reassignement but if you use const as a default, the linter, the LSP and the JS engine will scream at you. When you try to reassign something you can decide if it was a mistake or if you need a "let". Make sure your system is only moving in ways intended to... that is true in programming and a lot of thing like mechanics and anatomy

[@taragnor]

Using const is a good idea, first, it gives you some measure of protection against mistakes, second it highlights variables that are mutable so readers of the code can better keep track of them and lastly JS engines are always changing and the more they knows about your code, theoretically the more optimizations it can make. Knowing a variable is const allows for the JIT to make more assumptions. I don't know how much it can optimize today, but given JS is constantly getting recompiled each time you load up your browser or node, new updates could make your existing code run better.

[@tmbarral664]

lucky the girl being Jack's daughter as her dad surely showed her something great : how to reason. Kudos, man. Well done. btw, about const, for those of us who played with other langages, we know that an object is a pointer, a ref to the object. So making the var (the ref to the object) a const means we locked our ref. but that doesn't mean the object props are locked. This is, I suppose, why we aren't that suprised by this. But for someone who learn to program with python or js, I reckon that is a tad puzzling.

[@JacobPhillips-rf5db]

should i use `function` declarations over `const` = (_params_) => {} ? do i just forfeit the concept of hoisting?

[@dezkareid]

Sometimes I have problems with the meaning of const and how it works on JS. But I think is "better" than let when you need to store values and don't need to change the values of the variable. Using const can give clues to compilers, transpilers, optimization plugins, etc. At the end depends on your own criteria how you use the language

[@lukasmolcic5143]

the argument that you can mutate an object which the const is referencing while being the only half serious one doesn't really make sense either , const means that the reference will stay the same for its lifetime, not that the value its pointing to will remain unchanged

[@ltroya]

His ChatGPT response had a typo in "to feel like `thier` code is good" (8:06)

[@shaunpatrick8345]

We can use let and const to indicate that a variable will or won't be reassigned, so we should do that as it adds context for other maintainers. We can also use freeze to indicate that an object will not be mutated, which adds context for other maintainers, but nobody does it because it's a few extra key presses.

[@LewisMoten]

I need some hard evidence. Is there a performance hit using const vs let? Is the mutable content of array and objects his only issue? Const is just saying a pointer can’t be reassigned.

[@jherr]

FWIW, I've tested the performance aspect and there is no perf delta between let and const. And at least in how I use them between let, const and var.

[@kmwill23]

I don't use const because there is no reason to use const. Does using it give any performance enhancement over let? Does using it add or subtract complexity? Are you adding a premature design limitation that you may change later? Does using const add some kind of security in the client that can't be circumvented? Can you objectively state that using const adds to readability, or is that subjective? If someone is reading your code, are they caring whether or not a variable is variable or not?

[@kevinb1594]

Const in JS is different from Const in other languages. In JS, at a minimum const is a signal to other developers and future you that this value isn't SUPPOSED to change and/or that it is a complete throw away once a function has completed. Once you've scanned and parsed a const declaration, you shouldn't have to use mental energy to possibly track any logic that will change that value.

[@ShadowVipers]

I just recently went to a talk about input validation practices that suggested using a 2 state enum instead of a boolean... Sounded like a great way to cause type pollution IMO. I think their justification was to prevent oneself from passing in a boolean value into the incorrect argument position (ex: when 2 parameters of the same type are adjacent).

[@emmercm]

I appreciate the analysis, Jack. The talk didn't convince me, and I've been scratching my head about Twitter the last few days. JavaScript isn't the only language with this behavior, Java's 'final' is nearly the same.

[@jherr]

Interesting. I’m hearing other folks say that Java’s final semantics are const all the way down. I’ve been too busy to check into that though.

[@emmercm]

@@jherr it only affects variable reassignment, which is why they've added some immutable collection types to the JDK.

[@refeals]

did this talk happen on April 1st ?

[@outwithrealitytoo]

Do not confuse the moon and a finger pointing at the moon. Do not confuse a const reference to a variable value with a variable reference to a const velue; or indeed a const reference to a const value. Do not confuse a reaction to a poor talk about a topic, with a reaction video about about a bad topic.or indeed a reaction video to a poor talk about a bad topic. 'const' in C exists to allow values to either be substituted at compile time, or to indicate they can be placed in ROM rather than RAM; while also allowing helpful errors in debug builds. In an interpreted language their use is largely semantic. Just because it is impractical to shut every door (with a bucket of consts and freezes) does not mean you shouldn't make reasonable attempts to indicate your intentions. Golang suffers from a lot of people copying immutable parameters because they cannot just label references/pointers to them as pointing to immutables, but really what can be modified is a part of the semantic contract for a method/library, rather than something which should be envorced by a syntactic convension in the library. Saying "everything might as well be a "let" as far as the Javascripts handling is concerned" is a different thing from saying "pieces of code should not indicate which.parameters/labels as invariant". const is little more than a lint annotation in JS and its use (like all lint annotations it seems) is prone to error, dubiously applied and inconsistently policed - but might still be consideed useful until the masses learn to differentiate referneces and variables, and how to document their interfaces. Oh yeh... this is a good video I concur wholehearedly.

[@leigh8646]

I like your summary, its about developing critical skills and being able to form opinions and 'smell' when its not right. I think your video is talking about where I am trying to get to now, its taken a few years of coding to be confident enough to trust my opinion, whilst I build my baseline. So thank you.

[@codinginflow]

At least JavaScript devs will never run out of things to argue about

[@AayushGoyalderiva]

So the conference talks are also a click-bait now a days. Great!

[@ayubmaruf3074]

This is good. Your tone and reasoning is very easy to understand too. He should listen to you honestly mwehehe

[@solvedfyi]

What I heard was "do what you want, but let me be". I agree with that. Linters yelling at me to not use let, is not my cup of tea. They're variables. It's unsurprising that const doesn't work like Object.freeze, because we have to mutate things too much.

[@ythalorossy]

I often feel that conferences are just a "CONSTANT" cycle of repeated opinions and product promotion.

[@adnanhussain1460]

const has some its own benefits as well but using it in those scenarios which you explained, blown my mind, you're actually very right about those code blocks, thumbs up (y)

[@neomangeo7822]

Const to me is just a sane, reasonable good practice. I think it is useful to have a "defensive programming" type of mindset as it helps to prevent bugs. So if your default mindset is making sure you want to avoid bugs, and you can make sure a reference to a value can't be mutated (aka by using const) as that can help prevent bugs... then that seems like a good practice to follow.

[@imadetheuniverse4fun]

i still don't understand why it's less readable to know that "this specific name in this specific scope pointing to this specific object is not going to change". there are only two options as I see it: 1. const x = { foo: "bar" } vs 2. let x = { foo: "bar" } why is 1 less readable than 2?

[@yawaramin4771]

I think the argument is more so that it's potentially misleading, if you don't understand that `const` only prevents reassignment, it doesn't prevent mutation.

[@imadetheuniverse4fun]

@@yawaramin4771 so at the cost of a developer learning literally one thing (const refers to the variable name, not the object itself, people would rather have no way of keeping variable names in scope immutable. what an insane take.

[@astronavigatorpirx26]

Because: const x = {foo: "bar"}; delete x["foo"]; x["Hello!"] = "It supposed to be a constant..." and now x contains {"Hello!": "It supposed to be a constant..."}

[@rijkvanwel]

If at the end of the talk you are still unsure if someone is trolling or not, I think it’s safe to say they did not do a good job making their case

[@Suz4n650]

Hey Jack, Really impressive video, especially in the developer world! You did an amazing job of calling out the fallacies in that talk. The "nirvana fallacy" or the idea of a "perfect solution" is definitely one of the most annoying ones. It feels like it goes beyond just forgetting the daily reality of a developer: often the best solution is the pragmatic one, not the perfect one. A little caveat : while calling out misleading discourse is important, it doesn't necessarily provide a solution to the problem itself. This could still be true for other reasons, or by accident. This is a great topic for another video! I'd love to hear your thoughts on when using const makes sense and the trade-offs involved. Love what you do, keep up the good work!

[@jherr]

I didn't want it to go long. In short, I always use const, rarely if ever use let, and never use var because of hoisting. My reasoning is that I want to use every feature the language affords to write more robust and reliable code. And so I'm always going to be going for something that offers more guarantees (i.e. const) over let. A simple example would be this `const [count, setCount] = useState(1);` If I attempt to do `count++` I'm going to get an error because the count is const. But if I use `let [count, setCount] = useState(1);` then I can make that mistake. And I consider the const error to be an early warning sign that I'm doing something wrong. Not that I would make that particular mistake now, but starting out I surely did.

[@nvsWhocares]

Missed a big opportunity at 5:36. Should've applied the screaming case to the // LOL comments too

[@andrewgremlich]

Thanks for showing a critique, I appreciate it! The reasons that Ryan stated kind of don't make sense...

[@HemantKumarSaini-e4c]

Thanks for this video Jack, Very Nice Video.

[@Goshified]

This might sound dumb, but I stopped learning Remix shortly after it launched into open source (~3 years ago?) after noticing that all of their documentation was trying to push `let` over `const`. Originally launching as a closed source and paid framework, plus the weird pushing of `let` was enough for me to think that I'd have a lot of disagreements about how the framework works in general. Oh well, I've been pretty happy with Next for the past ~5 years. Funnily, it looks like Remix actually updated their docs to use `const` everywhere now.

[@jherr]

I went through something similar. I got an early license to Remix because I was like; Oh, cool, an alternative to Next. And I tried it and it was ok as I recall. Similar feature set just done differently. And then I watched a livestream with the Remix team going over how to do JS-less forms and Ryan was using `let` on a useState and some callbacks and I was like "Whut?" And I think he talked about it at that point and it the explanation didn't make much sense, and it put me off Remix for a while. It's interesting that the docs aren't picking that fight.

[@alexbennett5647]

Let's go, Jack! Speaking truth to power here. Love it.

[@zuma206]

It's not even satire, some of Ryan's videos on the Remix KZbin channel use `let` for useState calls..

[@jherr]

That's actually where I first time.

[@TM_LBenson]

I would have expected something about performance, memory management, or something technical. Its like people tell me to use function expressions instead of function declarations. If i start off using const, for the sake of consistance I will use it in my projects.

[@SufianBabri]

Good advice. This is unfortunately the way many KZbin channels are working nowadays. They make foolish arguments because it makes people laugh and have their lazy attitudes justified in not learning things which more useful practically than just learning a new shinny framework or language. I hear the same rants about Uncle Bob's Clean Code. You don't have to agree with everything the book says, (in fact Uncle Bob doesn't ever say that you're doomed if you don't do what he say) but apparently developers having 1 year experience 20 times hate the book and its basic rule of keeping code in unobfuscated form.

[@rreiter]

I've seen some really readable code that was wrong because of the absent "less readable" stuff it should have contained. For your purpose at hand, just use a language the way the language designers intended; if there are multiple syntaxes to choose from, or if you don't care because it doesn't affect the outcome, then go for readable. Since languages can change or be fixed over time, I don't make assumptions about the semantics of missing or broken constructs, and so I tend to be explicit and include constructs that show my intent: const where appropriate.

[@CelsiusAray]

It is terrifying to see how industries create trending phrases. And hearing developers repeat them without testing or even worse without knowing how to prove that a solution is the most optimal. Without any use of any scientific method to prove them. Jack Thanks for your content.

[@recursiv]

I've been in the industry since "don't use tables for layout".

[@daaa57150]

Every time I see a let in our code I ask myself how to change it to const because it's certainly doing too many things. It usually ends up a lot easier to understand after the refactoring.

[@luisbadolato]

7:24 Third line, thier instead of their. ChatGPT having typos smells kind of funky...

[@MrMurmandramas]

I got a bit triggered at that 5:00 example. When it comes down to value types and reference types, constants work pretty much in the same way - they don’t allow to change data stores in them. But the difference is that in case of array (reference type) you store a link to the object. And that link cannot be changed. And you can’t really mutate value types ie integers, you actually rewrite their stored value… I can’t imagine that someone could actually go to a conf with the above mentioned example and talk about it with a straight face.

[@MrMurmandramas]

P.S. and besides, mutating const objects is anyways a bad practice. If you are doing smth in a loop or other temporary environment it’s always better use a ‘let’ to specifically alert others that this piece of code is intended to be mutated.

[@snatvb]

so, when I see const, I can be sure, that the value will not updated below. If I see let, then somewhere it changes and somebody can add update after some time. I even don't use left for initialize with if: let user if (authed) { user = .. } I have this above code. By my optinion this is bad practice. It would be rather to do such: const user = authed ? .. : undefined then, I can be sure that below no one change value of "user"

[@poorusher]

They are just pointers but const points to a constant value, whereas let points to a value that can change. I think of them as placeholders rather than the term 'variable'.

[@weekendwarrior11]

Unfunny 10 minute powerpoint joke, or genuine bikeshedding? Who knows! But i like your breakdown of how to analyze these kinds of talks. That is good info 🍻

[@WiseGuyFTW]

Completely agree with you, I hate this "cool guys doing it or not doing it" reasoning to spit out baseless and false arguments.

[@nestorneto0]

working with JS for 2 decades now and since we had const I never faced any issues that he is describing... I am not sure why we are discussing this... is that lack of drama in JS world ?

In Rust variables are const by default. If you want it mutated, you must declare it mut. If a mutable variable doesn't change, there's a warning. So you see the code and can see perfectly which variables are mutable and not.

[@jherr]

Does the compiler check if you mutate your mutable variables and complain if you don't? Just curious.

@@jherr yes: "warning: variable does not need to be mutable"

[@jherr]

Interesting. FWIW, the eslint rules for airbnb give that a full error. Thus Ryan's issues with the airbnb lint rules.

@@jherr He he too harsh.

[@daromacs]

thanks so much for bringing this up, otherwise we as not that experienced devs would be confused by what to use afterwards, you know? this is an example that not every very experienced dev. must have the truth and we should question about it.

[@shekishral6570]

As a web developer myselfe I use const only when a variable / const/ object will never change, in all other cases I use let ( I found somehow always confusing that we are sometimes be able to modfiy a variable/object that is declared with const )

[@astronavigatorpirx26]

Agree. Like in react states for example or for loops. But actually it's just a matter of habit. Both approaches have a rational grain. You can use const for real constants only, or wherever possible. The main thing is that the programmer who writes and read the code feels comfortable (and the members of his team)

[@matttamal8332]

This is like my regular doom scrolling combined with career doom scrolling content all combined into a 10minute delight

[@garrettlong8629]

In the ChatGPT image, in the middle of line 3 there is a typo. "Their" is misspelled as "thier". Wouldn't ChatGPT have a dictionary lookup behind the scenes to fix common spelling issues like this? Like the red lines under the typos that provide the correct word when you right click on the typo. I can see an AI messing up complicated words, but having a typo on such a basic word is suspicious.

[@yawaramin4771]

Yeah, it seems pretty clearly that that response is faked.