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, 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.
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 researches say that within the span of time that you spend maintaining your code, 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.
Maybe even somebody that wrote it years ago and we're maintaining legacy code, as they say. Alright so we spend most of our time maintaining code, and researchers 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? No wonder the global average for lines of code written by a programmer is under five lines of code per day. Because we spend seven 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.
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 that many times people conflate these two. 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. 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 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 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 often times just assume everybody on the team's gonna know everything and we're gonna be super-hyper optimized, we're a race car that's going around the track at 100 miles an hour. I worked at this startup one time and the CEO of the startup used a stupid metaphor like we're a race car and we have to change the tires without a pit stop, right? That's the dumbest stupid startup metaphor ever, right? But that's kind of how we think about writing our code.
We're all 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 going to be a new person joining the team and isn't it always the case when a new person joins the 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? 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, and didn't always necessarily think about what's it gonna be like if somebody reads this and isn't already familiar? Is there a moderator question? Yeah. - [Man] Are there any links to this research? - 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.
If you google search 'automated code readability' you'll probably find it, but that white paper cites some other papers on this research. 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. 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.
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 another, 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 on 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: 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 would be the best code is if you swing that pendulum one way either way. 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, you would have to read every single line of that and trace through, essentially run the program in your head to understand what it's 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, right? I don't want you to have to go through and figure out what that is, I want to 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 numbers squared minus one and allows as much if possible, allows that to be taken care of as an implementation detail.
So ES6, the narrative that I want to leave you, or I want to start today, not leave you, I want to 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, 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 code that's more readable for those not already familiar with our code. So wherever possible today I'm actually gonna give you the before and 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, just 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, 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.
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 going to be things, and I'm going to disagree with a lot of my peers here, but there are going to be things that we've been doing that we're going to continue to keep doing. We should keep using certain features like for example, shockingly I'm going to tell you you should keep using functions, and I'm going to tell you you should keep using the var keyword. We'll go through all this stuff.
Just because we have the new stuff and there will be places where that will be more communicative, doesn't mean that the old stuff needs to necessarily be thrown out the window, okay? So look at ES6 as a way to improve the readability of the code, not throw away all of the old stuff that we've already known.
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