Check out a free preview of the full JavaScript Performance course

The "Parsing" Lesson is part of the full, JavaScript Performance course featured in this preview video. Here's what you'd learn in this lesson:

Before code can be executed, it has to be read. V8 parses code in two steps. This is a good thing, but can have some negative implications if we're not careful.


Transcript from the "Parsing" Lesson

>> Steve Kinney: All right, so we're going to go through each part of this. Parsing, so it's team's belief that the source code is the true intention of the application, but then you need to figure out what that means. Parsing is slow. Parsing takes a lot of time to take your like 10,000 line react application and figure out what it all means.

If I mean you go look at some minified code and see if you can figure it out. Parsing can be so slow it can be as slow as one megabyte a second on mobile, right? So if you're aiming for that one second load time like you've gotta get it to the user you've gotta parse it all.

Not gonna happen if you have a giant application. So one way to reduce the parsing time, again, this is the golden rule thing, right? Is [LAUGH] to have less code to parse. The other golden rule is to do as much parsing as you need and as little as you can get away with.

If there's things you can parse later, what do we do? Parse it later, so, the way that V8 parsing works is it's implemented in two phases. There's eager parsing, which is what you think about. Like, take the code, turn it into the ST, we're ready to rock, right?

That's, anything you think about parsing, if you think about parsing at all, like it's what you think of. Then there is lazy parsing, right, and who doesn't like laziness right? Which is to do the misspelled word bare. When I was practicing I also noticed that and never changed it.

Misspelled word bare like do what you can, like do this if you need now. Anything that you don't need to parse right now. Don't parse it right now, parse it later, right? Cuz that will make your application faster, you have no control over this. This is effectively what Chrome is doing under the hood to try make your application faster for you.

With a lot of this performance stuff, it's two people meeting in the middle. So you doing things that make your application faster and it is the browser vendors doing things to also make the browsers faster. And hopefully, together, we can keep up with the rising cost of JAVA Script.

Generally speaking, lazy parsing is a good thing, right? It follows the golden rules, it makes sense, it should be good. Cuz doing less work is faster, so how does it work? We scan through the top level scope, we parse all the code that's actually gonna do something. Like if there's a varx equals 2, yeah, we need that we're in the top level.

But if there's some function, like that function, we don't know when it's gonna get called. It could get called after an ajax request. Do we need to know all the details about what it does right now? No, skip it, we'll do it later, we'll parse it when we need it, let's get to the critical stuff right now and we'll worry about the other stuff later.

But that could bite us, right? Here's an example. All right, super, yeah, it's naive but const a is 1, b is 2, fine, right? Parse those, I'm gonna need those values. Then I come across this function. I'm like, that's a function declaration, I'm gonna skip that. Then what happens directly afterwards?

You need the function. So what really happens here is what?
>> Steve Kinney: We think about we lazy parse. And when we need a function we eager parse it. So what's happening in that code?
>> Speaker 2: It's out of order
>> Steve Kinney: It's out of order but we're also lazy parsing it and then we have to immediately eager parse it, right?

And if not doing stuff is faster than doing stuff doing stuff twice is slower than doing it once right. So the thing that makes our code faster and granted is that like a contrived example, absolutely right. But we'll see that every contrived example has some amount of implication for real world applications, right?

They are not the thing you should cite next time you do a code review and you want somebody to add parentheses around things. But they are definitely things that are worth thinking about.
>> Steve Kinney: So, if we actually wrap something in parentheses, as I mentioned a second ago, it will actually get eager parsed.

Does that mean that you should go ahead and wrap every function in your application in parentheses? No right? It's helpful to know that happens. One that's we we call micro-optimatization which is a long fancy word for saying I wanna get my co-workers to hate me. But two, like these things add up I'm like they totally do but two, there's an algorithm that's trying to help you there and if you wrap every function in parentheses you're basically opting out of all lazy parsing, which kind of defeats the purpose.

It works well most of the time if you notice there is a problem, right? You could theoretically solve it this way, better than that, there's usually libraries that will help you. This one is called OptomizeJS, you can imagine what it does, it optimizes JS with the help of parsing.

And I think what's kind of interesting here is that it will go through and try to figure out, not every time, to wrap everything in parentheses, because that would be bad, but like, known cases. What it does is it goes ahead and parses your code to figure out some of the common cases where did I have to go and immediately eager parse it afterwards, right?

And it'll go and fix some of these things for you.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now