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.
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..
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?
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.
@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 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.
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 :)
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.
@@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.
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.
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.
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.
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)
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.
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.
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.
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.
@@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.
@@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.
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.
@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.
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"
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.
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.
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.
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!"
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.
@@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.
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
@@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!)
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.
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.
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.
>> "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)}
@@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 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.
@@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.
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 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
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.
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 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
Why did he feel the need to include clearly and very obviously fake ChatGPT transcripts? Does he think that when ChatGPT agrees with him, that makes him more right?
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.
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?
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.
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.
This just gave me one more reason not to use Remix. If this is the person at the top, holy shit, this is just bat shit crazy talks. What did he smoke before this talk!?
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 👌🏼
หลายเดือนก่อน +1
Just so you guys know, Ryan's ChatGPT answer is fake. ChatGPT doesn't make spelling mistakes and Ryan's ChatGPT answer has one: "...to feel thier code is good". Maybe this was intended as a joke from Ryan. But FYI, Ryan faked that response :)
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.
were I there I would have walked out. It's like the tab/space debate. Obviously tabs are the only correct choice but I'm not gonna make a talk crying about it.
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.
Good advice. This is unfortunately the way many TH-cam 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.
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
Typical veteran’s tech mambo jambo with zero business value expertly picked apart by Jack! Btw I wish more tech influencers had stronger business orientation.
Literally some of the worst arguments ever. He's splitting hairs over scoping and variable ..sorry.. constant visibility. For our codebase, any true "constant" must reside with related constants in their own file, exported members in SCREAMING_CASE. Any transient variable must use "const", and no - the ambiguity over what a constant means is quite clear based on indentation alone. The only time we allow "let" to be used anywhere in our codebase is in a for-i loop initializer or be conditionally assigned in synchronous functions ONLY if a ternary is not practical, bearing in mind it's best to extract to a testable function using return statements within branches. Anything else can be computed and assigned to a "const" - not rocket surgery, just imposes stricter and more robust coding practices.
I prefer `const` over `let` simply because it guarantees it won't get reassigned. It might get mutated, but that's the risk of JavaScript in general. This is dynamically-typed language, so at least `const` tells me that something defined as an array will always be an array, not a string, because someone accidentally changed it. Regardless, this whole "use let" and "use const" is spinning out of proportion, and attaching any philosophy doesn't really make sense. I would much rather watch a presentation about consequences of using `const` and `let` interchangeably in one codebase.
This will probably be said after 4:30, which is as far as I got before I felt like it's time to say something. I'm really mad. JavaScript is a lot of things for a lot of people, but it is what it is and if you decide to work with it, your duty as an engineer is to learn what it is, no matter whether you like it or agree with its design choices. A const declaration creates a constant reference, a reference that cannot change its target. If you think that the targeted value - when accessed through a constant reference - should be immutable, sure, that's a valid point of view. But it's not JavaScript. When I see a const in JavaScript, I know what it is. When I see it in Swift, I know that both the reference and the target won't change - through the use of the constant. It's the same word or rather abbrevation but not the same meaning, but there are apparently more programming languages than words for programming language constructs. What Ryan is basing his opinion on is that JavaScript developers - unwilling to learn JavaScript - should document their lack of understanding by not using constructs expressing semantics they tend to misunderstand. What? Damn no, they just have to learn JavaScript. That's not that hard. It's our job as engineers to work with what we have. Engines need oil and sometimes faulty parts need to be replaced. But you can't just remove the motor because it will eventually stop working and expect a customer to accept the result. So when working with JavaScript, we should use const for a constant even if that only makes the name a constant reference and not a constant, because that makes the name reflect the reality better than let. Then we go on to say how much JavaScript sucks and continue to work with it.That sounds frustrating, sure, but it's not as if projects succeed any more just because management set a new timeline neither do we reach better results without timelines. Managers need to actually manage and that's difficult - surprise, surprise. I learned to be careful when using mutable state shortly after learning C, more than three decades ago. It's a painful lesson you remember after spending nights in a debugger. Ever since then, I'm not mutating a state unless I have a good reason to. Convenience is not a good reason. Such a reason is rarely self-documenting in code (loops are one exception). So I tend to document why I'm mutating state. My approach comes with a price. My code is often ugly because of that. I struggle with finding appropriate names for transitory state. That often leads to me refactoring code. The result is a better code quality.
Const is variable if you write anything that nests more than once... It also avoids juniors confusing scope so they can just work and practice reading, letting patterns sink in over time. Let is useful, const is useful, what isn't useful is var. Nothing useful about var except confusion. If a person says con instead of const, nobody would misunderstand. Horrible talk.
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.
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 🍻
'const' means the reference is constant, not what it points to. You'd think Ryan giving a talk on this and coaching AirBnB would know this. How to trash your own credibility 101.
The examples with modifying the array are laughable. If you really wanted immutability you could use specific tools like immutable.js or immer.js to manage updates. I think this presentation is geared towards junior devs trying to grab on new ideas.
Great video. I'm impressed by your patience. let vs const is such a boring irrelevant debate. It's like arguing about semicolons. It has never been the difference between a product shipping or not. I can't believe Ryan wasted time making this talk and wasted everybody else's time bringing attention to it. This is such a stupid waste of time. I hate this.
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!
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.
The naming is the main problem. If it was something else besides const, people would not have a problem with it. The let and const keywords are simply about whether the variable can be reassigned or not, and there is value in marking things as such. Anyway, regardless of whether this talk is a joke or not (it is whether or not that was the intention), this guy is a hack and nothing he says should ever be taken seriously.
5:00 This whole part is basically a lament about not being able to accept that "const" in JS means a constant reference to an object instead of a constant content and a constant return value. Big deal, right? No. Any programmer worth his salt is perfectly at ease with these abstract notions, in one language or another. Pointers aren't a new thing. If you can't even understand that, there's no point in pretending to know how to program.
OMG all the pretentious people... Even after the last part with the sound of let vs const you still believe this was a dead serious talk? It was clearly a light hearted talk about his like for using let. And a pretty funny too.
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 ?
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.
I use `const` for what it is. It might not be the best name for the declaration, but who cares. Once you know the meaning of a keyword you just use it.
I think this is just a satirical push back on the people that exclaim `const` is the only correct way to write js, he is just saying "actually, it doesn't really matter, let me be", in which he is right because like he has said "consts are only constant until they aren't" and you can still mutate them so the only real benefit it you can't reassign them, which is nice but not a reason to have a strong opinion either way like many have
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
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.
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.
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! 😅
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.
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.
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.
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.
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.
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!
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 🙏
An argument should be evaluated based on its intrinsic merits and logical structure, rather than relying on external factors like the authority of the person presenting it.
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.
Very well said
Yep, agreed 💯
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..
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?
Totally agree.
ChatGPT also spelled "their" wrong in its response... I think we can all take that accident to its logical conclusion.
touché
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.
@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.
@@bertilorickardspelarI think you missed the point of what the misspelling implies.
@@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.
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 :)
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.
@@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.
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.
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.
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.
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)
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.
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.
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.
I don’t see the problem with const = array[]. It’s a pointer to an array, that pointer never changes.
It would be preferable though if a const array contents were immutable though.
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.
@@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.
@@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.
Not in Rust. In Rust you can only use .push on a Vec that is mutable
I am convinced that the talk was a meme 🤣
It was. I thought the fabricated ChatGPT was a dead giveaway 😆
@@KentCDodds-vids 💯and I'm sure he got us good 😅
@@KentCDodds-vidsOops! I've already gone ahead and updated all production codebases to utilize 'let'. My bad! :(
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.
@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.
JavaScript community just running out of stuff to do conf talks about at this point
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"
I've been learning go recently because I'm tired of TS fake type safety.
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.
@@VeretaxCould you expand on your last sentence?
at 8:08 , i have never seen chatgpt spell their as thier before.
I saw that too. That was definitely a fake GPT response.
Good catch.
hawkeye
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.
yikes! replacing native maps with lodash's would've drove me nuts lol
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.
Did anyone approve the PR? Did anyone take your position?
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!"
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.
Not to mention that the chatgpt quote was obviously faked.
@@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.
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
@@JR-jx5ymLLMs make grammar and spelling mistakes from time to time
Always use const unless you need your variable to actually vary
I work at Airbnb and Ryan is blatantly lying. We 100% use const
Do you use the Airbnb lint config?
But he said you don't use eslint, not consts.
@@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!)
I thought that he was only talking about the eslint config.
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.
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.
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.
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.
>> "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)}
@@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.
@@gownerjones What about using let in cycles then? Do I declare a new variable every iteration? Like in for (let x=0; x
@@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.
@@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.
So the conference talks are also a click-bait now a days. Great!
Brilliant! That’s exactly how everyone should consume information critically. Not just in tech but with regard to everything.
This is how reaction content should be. Well done sir.
ChatGPT would not make a typo in "their"...
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.
You are correct, more precisely it's an anecdotal fallacy.
@@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
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.
Reminds me of the time a coworker said we should always nest ternaries and cited a Medium article to back it up.
Should've cited "Structure and Interpretation of Computer Programs, JavaScript Edition" book, it's full of them.
Ha! Many linter configs actually warn against doing these. :)
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.
@@Veretax If you 💭 it should be a separate component, it probably should be!
@@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
The misspelling in the "ChatGPT response", LOL.
Why did he feel the need to include clearly and very obviously fake ChatGPT transcripts? Does he think that when ChatGPT agrees with him, that makes him more right?
I’d be pretty annoyed if I’d gone to this conference and the talk turned out to not be serious.
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.
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?
Constant allows for you to mutate the data, but the object type doesn't change. It helps skip certain steps with interpretation.
At this point, we are in the protestant vs catholic sermons area...
It definitely had a sermon-esque quality to it.
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.
what a GREAT analysis!!! definitely love the critical approach, this is also the kind of thinking we need to use for code reviews
This guy made a long-form joke that just DIDN'T land with anyone in this comment section 😂Poor guy.
I often feel that conferences are just a "CONSTANT" cycle of repeated opinions and product promotion.
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.
This just gave me one more reason not to use Remix. If this is the person at the top, holy shit, this is just bat shit crazy talks. What did he smoke before this talk!?
Nothing apparently. He made it very clear during the talk that he is super sober. :) Not even any coffee.
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 👌🏼
Just so you guys know, Ryan's ChatGPT answer is fake. ChatGPT doesn't make spelling mistakes and Ryan's ChatGPT answer has one: "...to feel thier code is good". Maybe this was intended as a joke from Ryan. But FYI, Ryan faked that response :)
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.
were I there I would have walked out. It's like the tab/space debate. Obviously tabs are the only correct choice but I'm not gonna make a talk crying about it.
Tabs forever.
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.
Good advice. This is unfortunately the way many TH-cam 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.
It's not even satire, some of Ryan's videos on the Remix TH-cam channel use `let` for useState calls..
That's actually where I first time.
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
Typical veteran’s tech mambo jambo with zero business value expertly picked apart by Jack! Btw I wish more tech influencers had stronger business orientation.
Literally some of the worst arguments ever. He's splitting hairs over scoping and variable ..sorry.. constant visibility. For our codebase, any true "constant" must reside with related constants in their own file, exported members in SCREAMING_CASE. Any transient variable must use "const", and no - the ambiguity over what a constant means is quite clear based on indentation alone. The only time we allow "let" to be used anywhere in our codebase is in a for-i loop initializer or be conditionally assigned in synchronous functions ONLY if a ternary is not practical, bearing in mind it's best to extract to a testable function using return statements within branches. Anything else can be computed and assigned to a "const" - not rocket surgery, just imposes stricter and more robust coding practices.
He's really making up ChatGPT responses to prove his point? Weak. ChatGPT doesn't spell "their" incorrectly.
I prefer `const` over `let` simply because it guarantees it won't get reassigned. It might get mutated, but that's the risk of JavaScript in general. This is dynamically-typed language, so at least `const` tells me that something defined as an array will always be an array, not a string, because someone accidentally changed it.
Regardless, this whole "use let" and "use const" is spinning out of proportion, and attaching any philosophy doesn't really make sense.
I would much rather watch a presentation about consequences of using `const` and `let` interchangeably in one codebase.
Remix is full of zealots
This will probably be said after 4:30, which is as far as I got before I felt like it's time to say something.
I'm really mad. JavaScript is a lot of things for a lot of people, but it is what it is and if you decide to work with it, your duty as an engineer is to learn what it is, no matter whether you like it or agree with its design choices. A const declaration creates a constant reference, a reference that cannot change its target. If you think that the targeted value - when accessed through a constant reference - should be immutable, sure, that's a valid point of view. But it's not JavaScript.
When I see a const in JavaScript, I know what it is. When I see it in Swift, I know that both the reference and the target won't change - through the use of the constant. It's the same word or rather abbrevation but not the same meaning, but there are apparently more programming languages than words for programming language constructs.
What Ryan is basing his opinion on is that JavaScript developers - unwilling to learn JavaScript - should document their lack of understanding by not using constructs expressing semantics they tend to misunderstand. What? Damn no, they just have to learn JavaScript. That's not that hard.
It's our job as engineers to work with what we have. Engines need oil and sometimes faulty parts need to be replaced. But you can't just remove the motor because it will eventually stop working and expect a customer to accept the result. So when working with JavaScript, we should use const for a constant even if that only makes the name a constant reference and not a constant, because that makes the name reflect the reality better than let. Then we go on to say how much JavaScript sucks and continue to work with it.That sounds frustrating, sure, but it's not as if projects succeed any more just because management set a new timeline neither do we reach better results without timelines. Managers need to actually manage and that's difficult - surprise, surprise.
I learned to be careful when using mutable state shortly after learning C, more than three decades ago. It's a painful lesson you remember after spending nights in a debugger. Ever since then, I'm not mutating a state unless I have a good reason to. Convenience is not a good reason. Such a reason is rarely self-documenting in code (loops are one exception). So I tend to document why I'm mutating state. My approach comes with a price. My code is often ugly because of that. I struggle with finding appropriate names for transitory state. That often leads to me refactoring code. The result is a better code quality.
Const is variable if you write anything that nests more than once... It also avoids juniors confusing scope so they can just work and practice reading, letting patterns sink in over time.
Let is useful, const is useful, what isn't useful is var. Nothing useful about var except confusion.
If a person says con instead of const, nobody would misunderstand. Horrible talk.
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.
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 🍻
'const' means the reference is constant, not what it points to.
You'd think Ryan giving a talk on this and coaching AirBnB would know this.
How to trash your own credibility 101.
The examples with modifying the array are laughable. If you really wanted immutability you could use specific tools like immutable.js or immer.js to manage updates. I think this presentation is geared towards junior devs trying to grab on new ideas.
7:24 Third line, thier instead of their. ChatGPT having typos smells kind of funky...
At least JavaScript devs will never run out of things to argue about
Great video. I'm impressed by your patience.
let vs const is such a boring irrelevant debate. It's like arguing about semicolons. It has never been the difference between a product shipping or not. I can't believe Ryan wasted time making this talk and wasted everybody else's time bringing attention to it. This is such a stupid waste of time. I hate this.
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!
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.
The naming is the main problem. If it was something else besides const, people would not have a problem with it. The let and const keywords are simply about whether the variable can be reassigned or not, and there is value in marking things as such.
Anyway, regardless of whether this talk is a joke or not (it is whether or not that was the intention), this guy is a hack and nothing he says should ever be taken seriously.
5:00 This whole part is basically a lament about not being able to accept that "const" in JS means a constant reference to an object instead of a constant content and a constant return value. Big deal, right? No. Any programmer worth his salt is perfectly at ease with these abstract notions, in one language or another. Pointers aren't a new thing. If you can't even understand that, there's no point in pretending to know how to program.
OMG all the pretentious people...
Even after the last part with the sound of let vs const you still believe this was a dead serious talk?
It was clearly a light hearted talk about his like for using let. And a pretty funny too.
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 ?
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.
I use `const` for what it is. It might not be the best name for the declaration, but who cares. Once you know the meaning of a keyword you just use it.
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.
I think this is just a satirical push back on the people that exclaim `const` is the only correct way to write js, he is just saying "actually, it doesn't really matter, let me be", in which he is right because like he has said "consts are only constant until they aren't" and you can still mutate them so the only real benefit it you can't reassign them, which is nice but not a reason to have a strong opinion either way like many have
Would these conference talks not be more productive if they present solutions instead of subjective opinions?
"...who need easy-to-follow rules to feel like THIER code is good". Yeah nah throw that reason in the trash
This was such a terrible conf talk. This is when you know the conference shouldn't exist. What a reach.
Great video, I was waiting for a part which you share how typescript fixed this using as const and Readonly array
Completely agree with you, I hate this "cool guys doing it or not doing it" reasoning to spit out baseless and false arguments.
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
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.
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.
Also there is a typo in ChatGPT's answer '... to feel like thier code is good ...'
The guy presenting 100% wrote that himself. Super weird.
Won't be the first time an author regrets something. Case in point Node and Deno 👀
ALL of us have written code that we look back on with the thought "that could have been better"
That's a daily occurrence for me. :P
@@jherr yup 😅
Existence of OAuth2 too
I'm glad I'm not at that conf, what a disrespect to everyone's time
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
Thanks for showing a critique, I appreciate it! The reasons that Ryan stated kind of don't make sense...
Maybe it was kind of joke, on C++ conferences they have such lightning talks with funny contents
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! 😅
His ChatGPT response had a typo in "to feel like `thier` code is good" (8:06)
I did not like that talk. We have enough bikeshedding and division wars in frontend as it is, we don’t need to invent new ones
Damn, great video ! Small video and big punches.
Oof
"for (const rating in Object.values(RATINGS)) { ... }"
does NOT do what it looks like it does.
I had no idea what you meant at first. I was really blind to that 'in' instead of 'of'! Nice catch eagle eyes
I saw the talk. I put it under satire. I didn't see any real world value in the talk.
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.
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.
ChatGPT is going to sue the speaker for diffamation.
LLMs in two years will be trained using that talk :|
this has lowered my opnion of Ryan Florence quite a bit
Thanks for this video Jack, Very Nice Video.
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.
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.
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.
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.
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.
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!
Didn’t watch and now I really wouldn’t lose my time 😅
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 🙏
const correct_practice = "Keep using const"
An argument should be evaluated based on its intrinsic merits and logical structure, rather than relying on external factors like the authority of the person presenting it.