So don't feel like you're somehow behind or whatever if this is weird or confusing. It took me months to get comfortable with this stuff. Okay? And, I'm also fully aware that if I tell you something that takes an awful lot of learning that might seem to kind of betray the whole purpose of what we were trying to get here which was to try and make it easy for people to not have to learn a whole bunch of stuff to understand our code. So, that's another nuance, if you will that I wanna make sure we're clear on. Don't ever just hear me say I don't want somebody to have to learn something that is the antithesis of my message.
You're here today and you're in this workshop and you're watching this workshop because I hope that you have the same spirit as I do which is that my challenge for you is to learn deeper, to go deeper, uncommonly so. More than most of your peers do. And so I want that and I want to promote that. So don't ever hear me to say I don't want you to have to learn something that's not the point of creating readable, understandable familiar code. But, there is a difference between learning something that pays off only for that line of code and learning something that pays off for every line of code like it throughout code base.
And like, look how this thing just fits together with that and they just work right or whatever. You know one example, just to give you an example I love the fact that function dot prototype is, itself, an empty no-op function. So, instead of somewhere in my code writing over and over and over again, that or the arrow equivalent of it I like the little trick that I can just use function dot prototype in those places. Because I know it's just a plain old, simple empty no-op function and in places where I want that it's a nice, useful thing.
Okay, so I put a lot of learning in and I got one line of code right. But there are other tricks there are other techniques there are other patterns that we can use as developers that pay off in folds. They pay off bigger than themselves and in more places in our code than in just one spot. So, wherever possible what I want you to do is focus your attention on using and learning the things that pay off in a bigger sense as opposed to look how clever I can be on just this one little line of code.
Look how I can use the double tilde operator in this really weird way and I've saved myself a couple of characters but there will never be another case in my entire career where I see a double tilde so my time spent to learn that doesn't pay off very much. Does that make sense? Are you following me? This is a balance, there's a balancing act. Yes? - [Student] Question from the chat. What are your thoughts on the TypeScript? Similar to Babel? Different? - Uh, well. Similar to Babel in the sense that they both end up processing your code and producing a different version of your code that runs.
Different in that TypeScript's job is to take features that aren't part of the spec and make them work in a spec compliant browser. Whereas Babel's job is to take stuff that's either part of the spec or hopefully, maybe going to be part of the spec and make it work in the browser. So there's a difference there. In general, I mean I often get asked this. I often get asked, "What do you think about TypeScript?" I also used to get asked "What do you think about CoffeeScript?" And my answers kind of the same for both of them which is "Eh, I don't use them but "I don't have any problem with them." As a matter of fact I think it's a good thing that CoffeeScript existed.
So, I wouldn't ever recommend somebody write CoffeeScript today but I'm glad it existed and I think we need more of those. I think we need a thousand more experiments into language design so that we can practice with this stuff before we get it stuck and set in stone in our language and we can never change it because that's one thing. As soon as we make a mistake we're stuck with it forever. So, I think it's a great thing that we have explorations of that. And I think TypeScript is in the same vein. It's an exploration into A what could classes look like before classes were standardized.
That's one reason people use TypeScript because they were the first ones to kind of pioneer what we now know as the ES6 class syntax. I'm not a fan of that syntax but if you are a fan of that syntax TypeScript is a great place to have been working with that for quite a long time. And the other thing of course is that TypeScript is designed to add the type annotations thing in. So you have compiler enforced set of behaviors around what your types ought to be. Types have never been the source of bugs in my program.
Okay, so, let's now turn our attention to this destructuring thing. And, stick with me because it will be a little bit confusing. But I believe that if you give this the weeks of time and practice if you look for opportunities to use these techniques I think it will pay off beyond just those lines of code.
This course was created by Frontend Masters. It was originally released on 01/10/2017. We're pleased to host this training in our library.
- The arrow function
- Arrow function variations
- Closures and explicit blocks
- Default values
- Using the gather and spread operators
- Dumping variables
- Concise properties and methods
- Symbols, iterators, and generators
- Optimizing codes for the reader