ES6: The Right Parts Introduction

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

[00:00:39]
>> Kyle Simpson: This is my preferred place to teach JavaScript, so it's such an honor to keep being part of it. We just did a quick count. This will be my ninth course taught for front end masters, so that's pretty exciting. And I always tell this. It's actually, the first place I ever taught.

[00:01:00] Mark gave me my start as a teacher, called me up out of the blue and said I think you should come teach. And I've made a career out of it since then. So it's an honor to come back to that place and to talk to you about, I think maybe one of the most important topics that I've taught on.

[00:01:16] Which is really kind of beckoning towards the future of where the JavaScript language is headed. And that future, I believe, is very bright. It's a really good future. There was a long period of what we would call the dark ages for this language. And some of you like me, were around to experience that.

[00:01:38] To experience all the problems of feeling like the language was just dead, it was dead in the water, it wasn't going anywhere. And now we are in this period of rapid growth expansion of the language. And there are a ton of things that have been added over the last year or two.

[00:01:54] If you kind of been taking a nap for the last year or two and you wake up, it's not the same JavaScript anymore. You can't read a blog post these days without seeing an arrow function somewhere. Or some new feature that somebody wants, like the double colon bind operator, which isn't even in the spec yet but we already write code assuming that that thing is coming, right?

[00:02:14] So the language is rapidly evolving. And those of us who spend time writing and teaching about JavaScript have to grapple with what does that mean if I write something, and then six months later that thing is already obsolete? So it's a fun and exciting time for the language.

[00:02:35] There are a lot of amazing things added, and then there are some things that maybe aren't so great. And there's a lot of subjectivity of course, everybody has their own opinions. Today's class, ES6, The Right Parts, is designed to give you an opinionated guide through the things. Not just, am I saying these are the correct parts.

[00:02:57] But I really mean these are the right parts for you to focus on first. That's what I really mean by the title. What I really mean, is this is the right stuff that you should be paying attention to first. And I'm gonna give you my own personal take, my own narrative on why I think ES 6 is important.

[00:03:14] It's really all about using the tools that are now in the language, to affect a goal that I think we should have had for a long time that most of us really didn't adopt for. And maybe haven't even fully yet adopted. But it's become such a deeply held belief of mine as an educator in JavaScript, that you could almost call it a religious belief.

[00:03:37] That code is not about instructing the computer. Code is about communicating with other human beings. [COUGH] We are really good at instructing the computer on what to do. Many of you are expert developers. But how good are you at communicating to other human beings? Did you know that researchers say that within the span of time that you spend maintaining your code.

[00:04:00] And let's be honest. Most of us, our jobs are more primarily maintaining existing code. Not opening up a brand new blank file, and writing brand new code for the first time, all day every single day. Maybe you're lucky enough to have that job. But most of us spend our time developing on code that already exists, either code that we wrote yesterday or last week or last month or something that somebody else wrote on our team.

[00:04:24] Maybe even somebody that wrote it years ago and we're maintaining legacy code, as they say. Right. Right, so we spend most of our time maintaining code. And researcher say, in the time that you spend maintaining your code, which is the majority of your day, did you know that you spend 70% of your time just reading to understand the code?

[00:04:44] No wonder the global average for lines of code written by a deprogrammer is under five lines of code per day. Because we spend 7 hours and 49 minutes a day reading the damn thing before we can figure out what five lines to write and where to put them.

[00:05:00] Because we really, if we're honest about it, we kind of prioritize authorship of code. Don't we prioritize how quick and easy and fast it is for us to write our code, and maybe not so much pay attention to what it is to read the code? And I think many times, people conflate these two.

[00:05:21] If I can write the code easily, that means the code is easily read. The fewer characters I have to write, the fewer characters somebody has to read. These seem to go logically together, and yet actually, they fly directly in competition with each other. That same set of study and research that I'm talking about suggests that the notion of readability is not quite so subjective as we might assume.

[00:05:45] Most people probably assume that readability is all about your own personal preference, and there's no way to possibly make a statement about whether something is readable or not. And these researchers set about to figure out if there was a way to have an automated metric for this code readability thing.

[00:06:00] And they discovered that the most important factor that leads to somebody judging a piece of code as readable, is familiarity. Have you seen that code before, or have you seen that pattern of code before? If you have, regardless of how many characters it includes, you call it readable.

[00:06:19] And if you haven't, regardless of how many characters, you call it not readable. It's just simply, are we familiar with it? Now we oftentimes just assume everybody on the team's gonna know everything, and we're gonna be super hyper-optimized. We're race car that's going around the track at a hundred miles an hour.

[00:06:35] I worked at this startup one time, the CEO of the startup used the stupid metaphor like we're a race car and we have to change the tires without a pit stop, right? It's the dumbest, stupid startup metaphor ever, right? But that's kind of how we think about writing our code.

[00:06:51] We're all like this finely tuned machine, and we don't have to worry about bringing people up to speed. Except don't we? Isn't there always gonna be a new person joining the team? And isn't it always the case when a new person joins a team, you just sort of say hey, first two weeks, week or two, just go read the code to figure out what it's doing, right?

[00:07:15] Anybody in here like me, I had a lot of jobs and I was always told just go read the code to understand it. Do you know how much I actually understood from reading the code? Very, very little. Because I think that team probably prioritized writing the code efficiently as a team, as a well tuned machine.

[00:07:35] And didn't always necessarily think about what's it gonna be like if somebody reads this and isn't already familiar? Is there are moderator question? Yeah.
>> Speaker 2: From the channel, are there any links to this research?
>> Kyle Simpson: Yeah I will throw out some links to the research. There's specifically, there's a white paper that I've read about automated code readability.

[00:07:55] If you Google search automated code readability, you'll probably find it. But that white paper cites some other papers on this research.
>> Kyle Simpson: So, I think it's really important that we maybe put reader of the code, as a more important priority than writer of the code. So with that as our backdrop, we turn our attention to ES6.

[00:08:18] And most people think that ES6 is all about a whole bunch of brand new shiny toys that make us have more fun writing our code. And I'm gonna tell you that it's not so much about writing your code. But it's really more about making that code more readable.

[00:08:31] Specifically, there's a notion in programming, and maybe you've heard this before. But there's a distinction that we make between styles of code. And typically we can put code into somewhere in a spectrum, but into two camps, imperative versus declarative. Some of you may have seen frameworks out there that kind of sway heavily one way or the other.

[00:08:50] For example Angular, and it's very declarative, we put all of the stuff in the markup. And there are other frameworks which I think would be more in the imperative scale, like for example an ember or something like that. So we have this spectrum of imperative versus declarative. Here's how to put it simply.

[00:09:06] Imperative means telling the computer how to do something. Declarative means telling the computer what the end result should be. Let the computer figure out how to do it best. Okay. Now it is not the case that all declarative code or all imperative code is correct. That is not the case that that will be the best code is if you swing that pendulum one way either way.

[00:09:29] It is however, the case that many times declarative code used appropriately, used measured, used with caution, declarative coding style does tend to be more readable to those who are not already familiar with the program. If I threw up an algorithm here and I had a bunch of for loop and if statements and stuff.

[00:09:47] You would have to read every single line of that and trace through, essentially run the program in your head to understand what it was doing. But if I used a declarative form that just simply said here's the end result, I want all these numbers squared minus one.
>> Kyle Simpson: Right, I don't want you to have to go through and figure out what that is.

[00:10:04] I wanna just tell you that's what this code does. And a declarative form, a syntax that is a declarative form, says the end result should be number squared minus one, and allows as much of possible, allows that to be taken care of as an implementation detail. So, ES6.

[00:10:24] The narrative that I wanna leave you or I wanna start today, not leave you, I wanna start today with, is that ES6 is really about adding more declarative forms. So that we can take the idioms, all the stuff that we've been doing in our existing code, and express them in a way that will be, once somebody learns ES6, much more familiar.

[00:10:46] Because a person will not have to spend so much time reading through each of the details of the logic, they'll be able to recognize at a glance, the declarative form and know what that declarative form is doing. The goal being that we make that's more readable, for those who aren't already familiar with our code.

[00:11:07] So wherever possible today, I'm actually gonna give you the before and the after comparison. I'm gonna try to start with what we've been doing, and then talk about what we can now do. Not new functionality per se, virtually nothing in ES6 is something you couldn't do at all before.

[00:11:24] It's a few little things, but most of it is just a better way to communicate what we've always been doing. Okay, and I also want to point out this. Don't miss this point. There's an awful lot of narrative around ES6 that says blank is the new blank. Arrow is the new function.

[00:11:44] LET is the new var. We've rushed to this idea that all the new stuff means all the old stuff sucks. And it's legacy and it's bloat if you're using all the old stuff. And you'll actually find very little of that from me today. I don't think that there are very many examples in the history of programming, where that has held globally true, blank is the new blank.

[00:12:09] This is an additive set of tools that gives us more ability to communicate what we want. But all the existing stuff stays valid. We preserve backwards compatibility. As a matter of fact, there are gonna be things, and I'm gonna disagree with a lot of my peers here. But there are gonna be things that we've been doing, that we're gonna continue to keep doing.

[00:12:29] We should keep using certain features. Like for example, shockingly, I'm gonna tell you, you should keep using functions. And I'm gonna tell you, you should keep using the var keyword. We'll go through all of this stuff. Just because we have the new stuff and there are places where that will be more communicated, doesn't mean that the old stuff needs to necessarily be thrown out the window.

[00:12:49] Okay, so look at the ES6 as a way to improve the readability of your code, not throw away all the old stuff that we've already known.