Hello, my name is Steve, and I am an instructor at the Turing School of Software and Design out in Denver, Colorado. We are a seven-month developer training program, a not-for-profit, taking people who

want to become developers and turn them into the absolute best developers that they can be. If you are interested in mentoring some of our students, maybe on their first Rails app, their second Rails app, their third or their fourth Rails app, working with some TDD or some backend services or someone along those lines, please come talk

to me after this about mentoring. You do not have to live in Colorado. You should. Right? It's great. Right? The weather's wonderful, but you do not have to live in Colorado. Also, if you are looking to hire really amazing apprentices and junior developers, we can help you with that too. So also come talk to me after this, and we'll talk a little bit more about that.

So I was a liberal arts major, not a computer science major, and I majored in sociology. So I'm really, really interested in the kind of like the origin story of programming languages. You'd think with something that's like ones and zeros that there would be like a right answer, right, for like how you do a programming, right?

But it turns out that there's not. Right? There's a bunch of like trade-offs. Right? There's only one version of physics, but we've got like 9,000 languages. Right? So I'm really interested in like, you know, what were the decisions, what were the priorities in how that language came to be? You have a language like Ruby, right? Ruby was, it's not the fastest language in the world per se, right?

But it was, the trade-offs made there was a language that was simple and beautiful, a language that you enjoyed programming in, a language that made you happy as you programmed in it. Right? And those are Ruby's decisions on what it prioritized as a language, right? Other languages make different decisions. For instance, it has to be done in 10 days, and it needs to look like Java, right?

So different priorities for a different language, right? JavaScript started out as the Robin to Java's Batman, right? We're all going to use Java applets to build rich client-side applications in the browser. How did that work out?

Not particularly well. And all of a sudden, JavaScript started as a, you know, a kind of small niche, one where I even say toy language alongside Java, right? And it kind of rode on the coattails of a framework to rise to popularity.

So this is kind of the cornerstone of the talk, right? It's a language that I think we can all admit was not without its rough edges, right? And there's all, it's very much like, hey, here's this one weird trick for iterating over an object's properties, right?

And hey, let's talk about is it really, what is equality even, right? Or you know, what is a number? Not a number, number, right? Not a number does not equal not a number. And my experience in teaching JavaScript is that a lot of our students didn't really

feel super comfortable in JavaScript, right? Despite feeling comfortable in Ruby, right? And you'd think to yourself, well, you know, there's conditionals and like, it's kind of roughly the same stuff. Well, one of the reasons they didn't feel super strong in it is because you feel you have to memorize a set of like tricks and hacks to get anything done in the language, right?

So over the time that JavaScript kind of like went from this kind of accidental world's most popular language, right? We felt the need that like it's time to kind of address some of these concerns, right? The JavaScript language is standardized in a spec called ECMAScript. And the first version came out in 97, the second version came out in 98, in 99 we got

exception handling, that was cool, some regular expressions. And then work started on ECMAScript 4. And ECMAScript 4 was supposed to bring us modules and classes and a whole bunch of other like really fun stuff to make the language, you know, kind of fill out the kind of weird eccentricities of the language.

The problem is that it never shipped, right? And there was some side work on a spec called 3.1, it became ECMAScript 5. But over the time between 1999 and even 2007, 2008 when ECMAScript 5 started to hit the road, like the web became a much different thing, right? It became this thing that powered Gmail, it became this thing that powered many

like client-side applications on the net. So we kind of arrived at ECMAScript 6 and it is kind of like the first like major overhaul in a really long time to the language, right? And it brings us classes and modules and a whole bunch of really fun stuff and also

brings us a change to the approach, you know, even if we count ECMAScript 5, we're looking at eight years since the last iteration. So it involves a change of approach that like JavaScript is a living standard. It's not something that comes out every 10 years, right? But there's a whole set of features that we want to work on and over time, every year, kind of taking the few of those that are ready and bringing them

out into the browser for us all to use. So, and one of the foundations I think is really important and one of the things that we know that Ruby got really right was that syntactic sugar is important, right? It doing the thing you think it's going to do, right? Changes the way that you feel about a language, right? So there's a lot of features in this language, right?

A lot. And a lot of stuff that really kind of adds a whole bunch of new functionality and stuff that isn't even found in other languages. Today, I kind of really want to focus on talking about like just the firming up of the foundation of the language, making the language a more like reliable and solid experience, a language that you, that not only is the only game of talent on the

client side, but one that you feel comfortable and that you enjoy programming in the client. So I want to go over what some of those features are and why I think that they're going to create a better experience for you so you'll actually not do everything in your power to avoid writing JavaScript. So the first thing that we're going to talk about is a little change to the

semantics of the language. And it's not the most exciting part of the language, I'll admit that, but I think it's really important. You're going to see it a lot. So I'd like to talk about it so we can understand it. In JavaScript, as many of you know, we have this keyword var. Ruby, you just say x equals 2. You've declared a variable and you've assigned it. Great. Awesome. Right?

In JavaScript, we use var and that's, you know, partially because of that Java kind of syntax, right? In Java, Java is a statically typed language. We'll say something like int or, you know, char or whatever. We have var in JavaScript. And in Ruby, code like this would blow up, right? And rightfully so. You should not be able to use a variable before you declare it.

Makes sense? That's true in JavaScript as well. There's just some kind of like nuances on when you actually declared it. So in this case, what happens is the interpreter is going to go through these two lines of code, it's going to go pick up all the variable declarations and hoist them up to the top, right? So x is actually defined implicitly before we even started running this code, right?

And a two-line piece of code, not hard to get, right? Makes sense. But as your application grows larger and more complicated, little things like this that you weren't expecting would make you lose an afternoon, right? And they're what make you really kind of dislike working in a language. So in ES6 slash 2015, we have a new keyword called let, right?

And let pretty much does what you think it's going to do, right? Which is incredible for JavaScript. Here, this will blow up. And it will blow up the same way it does in Ruby insofar that you have not declared x because you haven't.

And it avoids the whole, you'll be like, all right, this seems cool. It doesn't seem like the biggest deal in the world. We have this little kind of example right here. I got five buttons, as you do. And I want to go get all of them. And I want to add an event listener on here. And we want to take a lucky guess what's going to happen when I click on each of those buttons.

You'd think I'd get one, two, three, four. But I'd actually get five all time, each time, because var is not even block scoped. It just leaks all over the scope. But if I was to change that to let instead, then I get exactly what you think I ought to get. And so I feel like that's the tagline for let.

Let. It's like var, except it does the thing you think it's going to do. I think it's catchy. I think it's going to catch on. It also has a cousin called const, which is like let, but you can't reassign it. So this is something that you might have seen in Rust or in Swift, this difference between using constants for things

you don't know are going to change. Because in my experience, most bugs are like mutable state that you didn't think was mutable state. So const is also there for us. Question I get a lot as I teach JavaScript is, hey, Steve, what is your least favorite thing about writing JavaScript? And I think many students are amazed at how quickly I can answer that question.

I hate string concatenation. I hate string concatenation so much. I think science has shown that on any non-trivial piece of code, you will miss a plus sign 1,000% of the time. And we do that a lot when we're working with jQuery.

So let's say, hypothetically, we've got a situation where, hey, I've pulled one of my musings and I want to append it to the DOM. Pretty straightforward, right? I just grab it. I make up some DOM. jQuery is going to handle all the DOM stuff of appending elements. I don't have to worry about that, except I forgot a plus sign, as you do.

So this is one of those things where it tends to wear on you. It tends to question some of your life decisions and why you chose this career. So if only there was a better way. And there is, right? There in extra script 6 slash 2015, we have this new kind of syntax of writing strings

called template strings. And they do a bunch of really great things. They do have a slightly different syntax because we don't like to, we don't, it's very important to us that we don't break the Space Jam website, right? Like, we cannot break the Space Jam website. It is a national treasure. And I'm pretty sure that team is not focused on that right now.

So we use a different syntax. We use these back ticks. And a back tick is, you know, instead of, like, a single quote or double quote. And also, it kind of ops us into a bunch of new superpowers. The first one being that, like, you can escape a line. It's cool. Don't worry about it. But more importantly, and near and dear to my heart, considering, like, my feelings on string concatenation,

is string interpolation, right? The Ruby is seen, you should see some similarities. In JavaScript, we like the dollar sign, right? We're all about the money. So other than that, it's pretty similar. And you've got, you know, you can interpolate in a variable or constant. That's totally cool. You can also interpolate in a full expression,

like you can in Ruby. For the most part, back ticks and dollar sign aside, works exactly like you expect it to work in Ruby. So that's pretty great. So this piece of code from before. I think I can refactor it. And this is what it can look like if we use template strings. We get line breaks. We can almost, like, write the HTML in there,

as if we were working with it normally, and just interpolate in our values, and kind of make the intent of our code a lot more clear. There's also a lot of other features. I'm not going to talk about all of them today in template strings. We can also, it's not just pure interpolation. We can actually create what are called tagged template functions that will let us do stuff to the values

as we kind of substitute them in. So for instance, if we're taking user input, and as we all know, users are bad people, and they tend to like to do script injection and other fun stuff like that, we can actually write a function that will go and sanitize all the inputs. We can write a function that will do all sorts of things as we kind of get those interpolated values in, and even create, like, full DSLs using tagged template strings.

And it's a really kind of exciting way to work with some of this stuff. I would like to play a game right now. The game is called, Guess What This JavaScript Does. You all ready? OK. So let's start with round one. Round one, we have an array, and we want to iterate over it.

And for each member of that array, I would like to console log n. What is this going to do? Jessica. It's going to console log one, and two, and three. Great job. 50 points. What is this code going to do?

I'll give you a second. Nothing. It's going to return undefined, undefined, undefined. And that's because JavaScript, unlike Ruby, does not, this is only half truth, implicitly return the last value in an anonymous function. We tack on a little return in there, we'll actually get the thing we think we're going to get.

All right. Round three. I got a person. And I got this update name method on there. And what happens when I call this update name method?

It's going to work. It's a trick question. It's going to work. You thought I was ready to spring another one on you. There's a rhythm here that we're establishing. It'll work. It'll work. I'll update my name to my son's name. That totally works. But a lot of times, maybe you want

to fetch that new name from the server. I don't know what it's going to be. So I might do some asynchronous action here, and also want to do the same thing. And when I want to take a lucky guess what's going to happen when I call the update name method now, you'd think that. It will not blow up, unfortunately. It would be better if it did blow up.

It will not update the name, silently. And then, whoops, I also just created a first name variable in the global scope. Sorry about that. Because in that case, this is actually scoped to the global object and not my current object.

So I apologize. There's a bunch of ways around this, and none of them are going to make you feel good. Sorry. The first thing that we could do is we could try to take the current scope, which is this, and assign it to a new value called self, or that, or underscore this, or a whole bunch of things

that are all going to make you equally icky. And then we can reference that value in our callback. ES5 gave us a new way to do this, which, again, for the number of times I explain it to the Turing students, it is almost impenetrably hard to understand.

We can use the bind method, where we can begin to, using bind returns a new anonymous function with some of the arguments already applied, the first one being the scope. So we create a new anonymous function with this applied to this you think it's going to be. Got that?

There'll be a quiz on this later, I promise. Yeah, so that works. But you might also ask yourself, well, if you can do that, why didn't you just do it? Why do I have to do this? So we get this new feature called arrow functions. And arrow functions look pretty simple. This is the syntax.

Here we're going to assign it to a constant called add. And there it is. And we've got the expression that would be the body of our function, along with the arguments, except in the other order. And under the hood, what it looks like is this. This is equivalent to writing the same thing.

So we can look at this code from before, our array of undefined objects. And we can rewrite as an arrow function. First of all, way prettier, right? Second of all, more importantly, maybe, is that it works. And we'll actually get the 2, 4, 6 that we had before.

The one thing you might notice is that if I only have a single argument, I don't have to use any parentheses either. So I get to even cut down a little more. Under the hood, you can do longer ones. But then you actually have to put in the return, right? You don't get to have the freebie. So you might be like, well, one of the things you just sold me on arrow functions were that they implicitly return.

And that's what Ruby blocks do. And I'm totally cool with that. Why are you lying to me? There's more. There's more. So the first example is that arrow functions also lexically bind the current scope. So we can actually take a look at what we had before and do a little bit of refactoring.

So we've got our bind.this example that we had at the very end before when we were trying to fix polluting the global scope and everything like that. And the first thing we can do is we don't need that function keyword anymore. We can change that to an arrow function. And we can also get rid of the bind.this,

because it's now implicit. Like, now that it's going to happen. And if I write an arrow function, this will be what I think it is at that given moment, kind of like what let does to var. Arrow functions tend to do that to our callback functions. We can actually take this refactoring a little bit further as well. We have some new syntax for defining methods on an object.

Previously, a method on an object was simply a function stored in a property. That's still true. But we can actually kind of just write that in a kind of cleaner, more concise fashion. And that's not the only new syntactic sugar that JavaScript gets. We also get this idea of classes, right? There's kind of the wizards of JavaScript

like to say that you can build classical inheritance with prototypal inheritance, but you can't build prototypal inheritance with classical inheritance. I don't really know what that means, but it sounds very wise. And I assume that it's true. The ability of the classes are basically syntactic sugar

over the normal way that you can build inheritance in JavaScript with a little bit of new features and a bunch of just kind of simplicity added in. So this is how we build a object currently in JavaScript. We create a function, and that capital P in person

isn't super important. It's just basically a convention saying, hey, I'm going to use this as a constructor. Don't just try to call this function. And inside there, we kind of get that this is implicitly the new object that we're constructing. And at the end, it's going to return our new object out. If we need to have some shared functionality in there,

we can store it on the prototype property of the function. And what happens as we're building the function, the very last step is that the object that is the function's prototype property, you following me on this? Gets set as the prototype of the new object. Cool.

I'm going to take that confused look on your faces that this is going right. And then we can just say new person, it runs our function as a constructor and does all the magic that it needs to do and everything works. Great. What happens if we kind of miss the new keyword?

I don't create a new object, right? I run this function over here as just a regular function, which at this point, this is set to the current scope. So I've just now created a bunch of new globals. I haven't actually made a new object, right? So we have person is actually undefined

and calling full name on it blows up. And then first and last name are actually now global, global variables. Sorry about that. So this seems like a very brittle way to write code. And I wish that we could refactor it a little bit.

As you can probably guess, we're going to. So we can actually use the new kind of class syntax. And the first thing we can do is we get this constructor method. From Ruby, this is very similar to initialize. And we've got this prototype thing here. We can actually move that into our class definition as well.

Under the hood, same thing's happening. Nothing has actually changed. The other nice part is that you've opted into strict mode, which means there's a whole bunch of dark stuff like the interpreter will stop you from doing. So it kind of limits your ability to accidentally create globals. You're kind of opted in by using new syntax into a safer version of JavaScript that again, behaves the way that you expect it to.

So if I have my new person, if I decide that I'm going to omit the new keyword, I'll actually throw an error. I won't silently pollute the golden name space. I won't silently accidentally create undefined. Like I will get the result

that I expect to get in this situation. This is just a quick side by side. Here's the same class written in the newest version of JavaScript alongside of the same definition written in Ruby. You can see that it is very similar to what you already know and love in Ruby.

So the next question is, what about inheritance? Right, we got that. We can say we have a developer who has a favorite language and that developer extends person. And the first thing we do is we call the superclass and use its constructor. So we can kind of start to, we can use the constructor from the superclass,

start building our object. And we can also, anytime that we need to, we can override methods, but we can also in that same time, just like really call up to the superclass as well and begin to use it. So we have our example from before, and we can do a little bit more refactoring. I know, crazy, right? So here we have it.

And there's a little bit of a problem with this code that I don't love, right? I've got my new person. If I want to get the first name property, I get the first name property. If I want to get the last name, I get the last name property. Problem is if I want the full name. Right? That's actually just going to return the function itself and not call it, right?

And this is one of the things that I think that Ruby does really well and a lot of JavaScript frameworks like Ember gets really right, which is this idea of the universal access principle. This idea that if I'm getting properties, I shouldn't need to have to refer to them in different ways. So in this case, I would have to use the parentheses if I wanted that value, which involves me remembering what are methods that are creating properties

and what are actual properties. It turns out that I can just create getters and setters. So here I can just define this as a getter function and now I can omit those parentheses from before and use it just like any of the kind of normal properties without having to worry about it too much.

There's a lot of other goodies in the class spec in ES2015. We've got class methods, properties, we can inherit from built-ins, right? Just like we can in Ruby. And a whole bunch of other computed method names. I totally, we'll talk a little bit about how you can explore some of these things. We've also got some extra syntactic sugar

in just our kind of day-to-day of working with things in Ruby. Here's a pop quiz again for us. Anyone know what this is gonna return? Yep, it's gonna return an array of one, two, and three.

Which is gonna be great. So what happens if we try to iterate over that? If we try to take the arguments and just log out each one individually.

Yep, we'll argue as for each is not a function because as it turns out, the argument is not an array. It's kind of array-ish, right? It looks like an array, it's got a bunch of properties, but it's not actually an array. So it doesn't have a for each method. And we have a bunch of ways of dealing with this. We could, for instance, borrow arrays for each

and call it with the arguments to use that. We could, for instance, use slice to turn the arguments into an actual array, to turn Pinocchio into a real boy here and iterate over it. But this is going back to what I said before of using JavaScript previously involved memorizing

a bunch of weird tricks and committing them all to memory and pulling them out as you needed them. And for somebody new to JavaScript, that becomes very difficult and very intimidating. So in the future, we have the splat operator. Well, it's spread operator in JavaScript,

splat operator in Ruby, which will take arguments and that'll be a real array inside of that function. So this'll kind of do what you think that it does. We can use it as the last argument, so we can define something, catch all the rest of the arguments in array, and work with that as well. And like Ruby, it works the other way as well. If we had an array of arguments

and we wanted to pass them in, like split up as the actual arguments, we could actually do that as well with the spread operator. We also have some syntactic sugar for working with different objects. So this is a tweet. If you've ever pulled anything from the Twitter API, there's a lot of stuff that you get.

And I don't want all the stuff. I just want one or two properties out of that object. So this syntax over here will allow you to kind of split up the properties of that object and define them as independent variables. So then we can log out just one of them. We can also use that in our functions. If we want to take an object and automatically assign different properties

of that object to local variables, it's totally there for us as well. We also get default arguments, right? And again, Ruby has had this for a while now, I think since 2.0 forward. Previously, we'd do maybe something along the lines of this, but now we can just define it as a default argument.

So there's a lot of really great stuff and a lot of like, hey, I don't have to memorize all these like strange tricks or like weird incantations anymore. So the big question is, that's really great, but my user base isn't on Chrome Canary and Firefox Nightly, right? How long am I gonna have to wait to use this stuff? Because it's all over right now, right?

In frameworks like Ember, you actually, it's built in and you like, you get all these new features today. But even in your Rails app, you're just building a regular Rails app, you can use that stuff right now. How? Transpilation, right? Transpilation, if you've used Sass, if you've used CoffeeScript, or anything along those lines, you know that you can write in other kind of languages

that like compile down to JavaScript, right? And we can kind of take advantage of that to use the new features that aren't fully in the browser yet, or maybe want to support older browsers, we can use those new features right now and as the evergreen browsers update every six weeks and kind of adopt these new features,

we can just slowly roll back the transpilation, right? Kind of the, there have been a bunch of different transpilers over the last few years, Tracer being one, the biggest one right now being Babel, which will allow you to write ES6, ES2015, and even some ES7, right? New features that are coming down the pike

and use them in your Rails application right now. So let's talk about how to do that. So let's start with Rails new. You'll be like, he's 28 minutes in, what is he doing trying to install transpiler in my application right now? Don't worry. We'll use JavaScript instead of CoffeeScript, just for fun.

We can install Sprockets ES6. Babel is gonna be supported by default in Rails 5, there's a new announcement for you, so I've read on the internet, I'm in no position to make announcements. The internet tells me that it will be supported.

You can use it right now by using the Sprockets ES6 gem. And we can bundle that up, and we can generate a new resource, and all that we need to do is append a .es6 file extension, the ES6 pipeline will take care of the rest, right?

It'll take care of it like it was CoffeeScript, like it was Sass, and we're good to go. That's it. That's all you have to do, right? You can use all, you don't have to wait, you can use all these new features, like literally 10 minutes from now. And we got a bunch of new stuff from ES6 that we talked about. We're also gonna get a bunch of stuff

from kind of future, there's already some ES7 features like rolled in that you can use right now and try out before they're used. The other thing it allows you to do is be part of the development of JavaScript, right? So this is how TC39 kind of like looks at, TC39 is the community that works on JavaScript.

And these are kind of the phases that a standard goes through, this idea of like an initial spike, initial like I have this idea, I wanna kind of work out an initial trial to see if it's a really valuable thing. And then the idea is, rather than sitting around and deciding what the language is gonna look like, trying to get these features out into the hands of developers now, right?

You all are gonna be the people that work with this stuff every day, right? So getting out there, trying it out, like figuring out what the weird edge cases are, right? To kind of prevent edge cases like have shown up in the language in the past, right? And to use these things right now, kick the tires on them and get a sense for them. Everything from stage two onwards is on by default in Babel.

So the second it started to like take a serious shape, but you can actually opt into experimental ones and try out new features as well and get a taste of what the future JavaScript is gonna look like and participate in it more importantly. Also, you can kind of just try it out, right? If you just wanna like see what the language looks like

and what it does and what you can do and what you can't do, you can go outside and just take it for a spin. You don't have to fire up a new Rails app, right? You can kind of just play and explore as well, which I think is super important. Like I said, we talked about firming up the foundation of the language today. We talked about like making it, turning it into the language that you will enjoy using just as much as Ruby.

There's actually a lot of new functionality that's really kind of great and beyond the scope of this talk, right? And I'm more than happy to talk, I will literally talk about this stuff all day, right? But there's a whole bunch of really great and new stuff that I really encourage you to try out and use. And on that note, thank you so much.