ES6: The Right Parts Audience Q&A: TypeScript vs JavaScript

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kyle Simpson: So let's go back to our discussion. Again, we're going to keep in this pattern of looking at the declarative form versus the imperative form. First, we'll look at an imperative form and then a declarative form. The next feature we want to turn our attention to is, I think without question the most complex and by complex I mean lots of steps to learn.

[00:00:30] Of all the of all the JavaScript features out there and certainly of all the ES6 features, okay. And, I'm fully aware that when I present something to you that has a high, Level of learning, that the first 30 minutes that I'm talking about this topic. It's gonna be a little bit confusing and that is totally okay so don't feel like you're somehow behind or whatever if this is weird or confusing.

[00:00:56] 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 to make it easy for people to not have to learn a whole bunch of stuff to understand our code.

[00:01:15] So, that's another nuance, if you will, that I want to make sure we're clear on. Don't ever hear me to say I don't want somebody to learn something right. That is the antithesis of my message you're here today and you're in this workshop you're watching this workshop because I hope that you have the same spirit as I do which is my challenge is for you to learn deeper to go deeper uncommonly so more than most of your peers do.

[00:01:41] So, I want that and I wanna 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.

[00:02:00] For every line of code like it throughout your code base. And that's the difference I wanna draw here. There are all kinds of tricks. As a matter of fact, I've thought in the past about maybe writing a book. And maybe someday I will just for the fun of it.

[00:02:14] Maybe writing a book about all the crazy esoteric tricks that JavaScript programmers can pull. Because, there's all kinds of tricks that we can play in our code. It's a very sophisticated language when you start really poking at all the edge cases and there's a lot of cool stuff that we can do.

[00:02:30] And that's fun, right? I'll be the first to admit, it's fun when you can pull some kind of trick out of a hat and look how this thing just fits together with that and they just work right, or whatever. One example just to give you an example. I love the fact that function.prototype is itself an empty no up function.

[00:02:52] So, instead of somewhere in my code writing over and over and over again that or the arrow equivalent of it I like that little trick that I can just use function prototype in those places Because I know it's just a plain old simple empty no up function and in places where I want that that's a nice useful thing.

[00:03:09] So there's, that's just one example of 100 right just little tricks that we should, that we can know about the JavaScript language. But the fact of the matter is that these tricks can be divided into This spectrum where there are some tricks on this side of the spectrum that if you learn them, they're really only going to pay off in that one spot.

[00:03:31] Put a lot of effort into understanding how this one statement work. But, you're never going to see that ever again throughout the entire code base. Okay, so I put a lot of learning in and I got one line of code red. 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 all bigger than themselves and in more places in your code than in just one spot.

[00:03:58] 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 I can use the double tilde operator in this really weird way and I've saved myself a couple of characters But there'll never be another case in my entire career where I see double till day so my time spent to learn that, doesn't pay off very much.

[00:04:25] Does that makes sense, are you following me? This is the balance, there's a balancing act to play, yes.
>> Speaker 2: Question from the chat room. What are your thoughts on typescript? Similar to babble, different?
>> Kyle Simpson: Well, similar to babble in the sense that they both end up processing your code and producing a different version of your code that runs.

[00:04:48] Different that type scripts job is to take features that aren't part of the spec. And make them work in a spec compliant browser. Where as bubbles job is to take stuff that's either part of the spec or hopefully maybe gonna be part of the spec and make it work in the browser.

[00:05:09] So, there's a difference there. In general, I mean I often gets asked this. I often get asked what you think about TypeScript? I also used to get asked what you think about CoffeeScript? And my answer is kind of the same for both of them which is 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 Coffee Script existed.

[00:05:30] Many of the great things that we're seeing in year six are here in large part, large part because CoffeeScript first pioneered whether or not it could even work in the JavaScript ecosystem. I think that the good parts of CoffeeScript made it into ES6 for the most part, right.

[00:05:49] So, I think it's a great thing that CoffeeScript existed. I wouldn't ever write a line of CoffeeScript again I'm pretty sure coffee script is like DOA at this point, right. Like it's a dead horse. So, I wouldn't ever recommend somebody write coffee script today but I'm glad it existed and I think we need more of those, I think we need 1,000 more experiments into language designs that we can practice with this stuff before we get it stuck in, set in stone in our language and we can never change it.

[00:06:17] 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 that same vein it's an exploration into a what could classes look like before classes were standardized.

[00:06:33] 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.

[00:06:49] And the other thing of course is the typescript is designed to add the type annotations thing in so you have a compiler enforced set of Behavior around what your types ought to be. Types have never been the source of bugs in my program so typescript isn't the tool that I reach for because I don't have that problem.

[00:07:08] But there are certain places where that problem is absolutely valid and if you're writing for example all day long if you're switching back and forth between JavaScript and .NET. You probably ought to be using typescript because it just makes a lot more sense To keep in the same mental context.

[00:07:23] It's not my world but I think it's a good thing that that exists for those sorts of use cases so hopefully that answers, the opinion. Okay. So, let's now turn our attention to this destructuring thing and stick with me cuz 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.