JavaScript Performance

Slimming Dependencies

Steve Kinney

Steve Kinney

JavaScript Performance

Check out a free preview of the full JavaScript Performance course

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

Steve states that not every part of a library is needs to be included in applications. In some cases, picking out only the parts needed is possible. Steve selects the one method he needs from Lodash and then re-evaluates the size of the application's bundle.


Transcript from the "Slimming Dependencies" Lesson

>> Steve: But the first thing I'm thinking about, is the lodash over here, right. Even gzip it's 23 kilobytes, right. I happen to know having written the app, that I am using exactly one method from lodash, right. And so because I included one method from lodash, I have to get all of lodash and pay that cost.

So then there's an argument of do use lodash? Do you write yourself? Like, how long do you wanna start walking on that path before you proven lodash? Slowly but surely, if only there was a better way. There are some libraries, that will allow you to be more specific about what you need from them.

So what I can do here, is I can go into the code, and let's take a look for where it is, I believe it's in the note view container, nope.
>> Steve: There it is, bring it in, the underscore from lodash, which has got all the methods that lodash does, right?

Like, I don't know how many methods lodash has these days, but it's enough to take up a large chunk in my bundle of visualizer. Cool, so it turns out with lodash you can do this really cool thing, where all I'm using is the transform method. Cuz I have an object with keys and values, I need an array, so I'm using the transform method and I'm turning it into that.

But what I can do is I can type lodash/transform, now we'll just call this transform. We'll get rid of that. First of all, it means I don't have to type that lame underscore all the time, so that's a win. Let's go ahead, and rebuild and see what happens.

>> Steve: Building is fun.
>> Steve: My suspicion, is that I'm going to get a smaller bundle. We will see this together.
>> Steve: Cool, so before, this is what we had, right. Now, code mirror still large and in charge, but lodash we're using lodash that is equal. Transform is not just transform, it uses some other lodash methods, so not totally out of the woods here.

But, I went from 500 kilobytes that's not my 300 kilobyte goal, and like think about how simple this app is I already blew past 300 with like aside bar, a mark down note and an editor. It means the 500 we're now down to 450, so it's shaved 10% of he size of our bundle by typing like 10 characters.

I'll call that a win, right? And you might be like, listen I use a lot of lodash, I'm not going through the files and doing that for every single thing. Luckily, you can cheat which is kind of great, there is a babel plugin that when it compiles your code will automatically switch out.

Every time you use lodash for the require lodash slash whatever, and just do it all for you. We can turn this code back,
>> Steve: The way it was, so again, incurring that 50 kilobyte tax again. And I have it in this package json, so you can see it

>> Steve: Babel-plugin-lodash, and its sole job is to do what I did, in all the files of your application for you, right? And so, if you have a large application and you're like, I don't want to do this by hand because I'm to good for that and it's very nice out.

You can install this plugin and you can be done. So we'll go to the babelrc, and we'll say plugins, I would also like to use the lodash plugin.
>> Steve: So remember I turned the code back to the way it was, I originally started out with. And so my hope is that it will basically rewriting my code for me at compile time.

I think one of the really interesting things that's going to happen to the web over the next kinda few years, which is before everything was happening in the browser, like how much stuff can we do in the build pipeline? How many things, how many optimizations can we make?

We saw optimized JS earlier, you can see it again now. You can see these are effectively indistinguishable. The code is slightly different because like we rewrote it. But I started with the original code, I used the babel plugin, I still get to have my 50 kilobyte savings, right great.

All right, but there are some other culprits in here, like we can all see the elephant in the room here. Who's the problem right now? Codemirror is the problem, codemirror is accounting for of my par size, or even my js size, the lions share. It's pars 162 kilobytes, gzip 53, right.

That is again, effectively like a third of my bundle, right. And again, if they never click on edit they will never even use this code. They will pay the tax to parson it, they will pay the tax of downloading it, they will never actually use it, and my app would be a lot snappier and quicker to load if I just didn't do this.

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