The Cost of JavaScript

[00:00:03]
>> Steve Kinney: So let's get into it. You ready? Very cool. So we're gonna talk about, first, JavaScript performance, as I promised. So the Ruby On Rails philosophy, was that developers are more expensive than faster server. So make a language that even if it's a little slower. And a framework that even it's a little slower, increases developer productivity.

[00:00:29]
Because you can send the money you were gonna spend on ten more engineers, to get this thing out the door, and buy a beefier server. That's a philosophy. It doesn't work for client-side applications, because we can't buy all of our customers new computers. Like here, everyone, here's a fancy Mac Book Pro.

[00:00:48]
Here you go, I don't wanna solve my own performance issues. I mean you could do that, but that's probably not a good idea, that's probably not a way to stay in business. So we have to think about these things. We can compress assets. We can reduce latency. But this application's eventually going to need to be run and built, and you don't get to control, the computer that it's run on.

[00:01:10]
So we, as Front-End Engineers, unfortunately, have to bear this burden of thinking about performance, because we can't buy faster servers and beefier machines. So before I showed you just the size of a webpage, as a whole, the size of the JavaScript that we're sending, is also growing at a very large rate, right, 500% on mobile.

[00:01:35]
The problem is, there's a philosophy, well, if I chip in an extra meg of JavaScript, if I include one less JPEG, that should be the same, right? You just want some of those. The problem is, again, JPEG, you show it onscreen. JavaScript, you need to parse and compile it, and in a lot of applications, that's actually the big culprit here.

[00:01:59]
This is the application I work on. There's a few things to notice. This is loading the editor, that I showed you in that screenshot earlier. Down in the lower left hand corner, you can see where the browser spent most of the time. That thin little blue stripe is loading.

[00:02:19]
Now, I was in Denver. The data center is in Chicago, it's not that far to get. This would be very different if I was in Australia, or Bangalore, or London. But I was not too far from the servers, it would probably even be closer here. I spent the majority of the time scripting, which is parsing and compiling the Java Script.

[00:02:39]
And a little bit of rendering, painting stuff along those lines. The other part at the top, is basically what the CPU was doing at any given point. So you can see that the yellow is parsing JavaScript, which if you look at the pie chart down below it's not like, wow, I can't believe that these are very different.

[00:02:59]
They're relatively the same thing. And this is a lot of the times called the big yellow slug. If you do it like a create react app, and nothing in the application watch and see this later. Like you're still gonna get a certain amount of this, cuz we're sending a JavaScript application.

[00:03:14]
There's nothing in the HTML, originally. We send this JavaScript application has to figure out what to do. These little red bars at the top, are when I literary pegged the CPU, right? I was using it at 100% capacity to build this. You can also see there's this graph in the middle, called a flame chart, which is, you've got at the top, these top level functions.

[00:03:36]
Then if that function calls a function, it's one layer down in the flame chart, and you can see that I could scroll [LAUGH], and more would happen here. Chrome is actually really nice, where those little red triangles on the upper right, of any given thing in the flame chart, that is where Chrome has figured out like you're doing a bad thing.

[00:03:56]
Let me tell you about the bad thing that you're doing. Sometimes, it can give you something helpful, we'll see that later. Sometimes it's like, no, this is just taking too long, and I think you should know about it. So you can kinda get a lot of really useful information.

[00:04:09]
But the point that I really wanna make on this slide, is that most of the time that my application is running, it's parsing. I can gzip some more assets, I can put something on a faster, a better CDN, and stuff along those lines. But that's not gonna solve the 2,800 milliseconds, the two, almost three seconds that I'm spending, just parsing and compiling my JavaScript.

[00:04:34]
So what is happening in that yellow part? Right, we feel like, yeah, that yellow part, it's too big, it should be smaller. [LAUGH] Right, okay, how does any of this stuff work? So it turns out that JavaScript is a compiled language, just like C or Java, it is put through a compiler, and out comes, some byte coder, some machine code, right.

[00:04:58]
You have other languages that are interpreted language where it runs through it, but JavaScript is compiled. You're like, I've never compiled in JavaScript. I mean, you might've run it through Babel to make more different JavaScript, but I have never produced a binary of JavaScript. That's because it uses a thing called just-in-time compilation.

[00:05:15]
Which is, the JavaScript code is compiled, like moments before it's executed, on your user's machine. And that's why we saw the big yellow slug, if you will. So we're not compiling it, it is getting compiled, just not by us. Cool. So just in time compilation. It means it is compiled, it means it's compiled moments before execution.

[00:05:43]
It means it's happening in our client's machine. It means that they're paying the cost, and doing the hard work for us. All right, so what is happening in the compilation part? We've identified it as a problem. Were gonna focus, each browser has a different engine. Chrome has an engine called V8.

[00:06:02]
I believe that's what Oprah uses as well, these days, that wasn't true a few years ago. Safari has one called JavaScript core, or when their talking about marketing materials called Nitro. Firefox has one called Spider Monkey, and there's a few other engines in there, Ion Monkey, and a few other ones.

[00:06:21]
Has one called Chakra. So each one has a different engine, they do work differently. We're gonna just focus on V8, because getting really in the weeds on the differences between all of them, is probably not the best use of our time. We're trying to get this high level understanding.

[00:06:36]
So I am going to do, not the best web standards thing in the world, but make believe that V8 and Chrome is the only browser right now. Don't do that, that's rude, but, [LAUGH] I'm doing it. So our JavaScript lives in this thing called, the cloud. I don't really understand what that is.

[00:06:52]
But I understand that's where when I do a web pack build, I put it in the cloud, and there it is, and people get it from there. Beyond that, that's the back end team's problem. I've heard it's an S3 bucket. I don't know. So we send the JavaScript to the browser, and then we have to parse it.

[00:07:11]
Okay, you've sent me those long string of text, what does that mean? We turn that into what's called an abstract syntax tree, which is an actual data structure that represents what this code actually means. That then goes to a baseline compiler or an interpreter. In Chrome, these days is a thing called Ignition.

[00:07:29]
Get it? It's V8 Ignition. Mm hm, they're doing a thing here. Google's really good at making sure that their technologies are un-Googleable. Go, as a programming language, good luck, trying to Google that. Ignition and turbo fan, which we'll talk talk about later, also impossible to Google for when you're doing research for a workshop, I'm not better.

[00:07:51]
That gets turned into byte code, that gets executed by the browser. But wait, there's more, we'll talk about later, JavaScript is really hard, it's this dynamic language, It'd be great, if we could make some of it faster. So there's a second compiler in there. This one's called Turbofan.

[00:08:09]
Get it? It's the same, yeah. And it's an optimizing compiler, that then looks at the code, and tries to make it even faster. That will spit out, well, any code that can be optimized. Any code that can't be optimized, same thing we saw before with the interpreter. Any code that can be optimized, goes to the optimizing compiler to get optimized, whatever it does in there.

[00:08:32]
And then, that's spits out highly optimized machine code, unique to that whether it's RM, or X86, like Intel, whatever, that shoots at the other end. Some cases though, you're super optimized code, isn't gonna work out, right? It's not actually valid for reasons that we'll talk about. At which point, we go back to using the slow byte code.

[00:08:55]
So it stands to reason, that red arrow's bad. If you can get stuff on the green arrow, that's good. And like, that's the goal. And any time we end with the red arrow, that's not good, right? And so, one way to make your application faster, is more green arrows, less red arrows.

[00:09:13]
You can all write that down. [LAUGH] Doing less work, more green arrows, less red arrows. Shorter yellow slugs. None of those notes will make any sense to you, a week from now, but I think it's really important that you capture them at this point.