Kent C Dodds: Okay, this is one of the earliest features of Webpack. This is actually, this feature is why Webpack was originally created. Tobias decided he needed some capability to only load code when it was needed. And none of the bundlers really handled that very well. You'd had to do a lot of stuff yourself.
And so, he created bundler, this amazing guy created a bundler just to handle that use case. And so, you can imagine it like this. I'm on the mobile or I want to go to Twitter. And so, I'm on my own mobile browser and I say, okay, mobile.twitter.com. The last thing that I, as a user, want to do is wait.
And so, all that I care about is what's going to be on my screen when I get there. And so, what codes, the whole why around code splitting is get things to the user as fast as possible. And that means as little code as possible, we should be sending as little code as possible to the user.
And so, when I log in, now, suddenly, I need all of the code for the login. So, if this is like a single page out, then, I need all of the code for the Twitter stream, and I need the code for settings. And, well, even potentially settings could be, yet, another area where I load stuff in late.
So, the whole idea around it is only load the code that's needed for where the user is going. And so, that is totally possible and actually, fairly simple with Webpack. You'll notice over here on this previous step, we're checking out a separate branch. So, originally, we went to tree shaking branch to get the tree shaking stuff.
We're actually skipping over another branch because we're going to actually considerably change the app in ways that aren't totally relevant to you. So, we're actually adding react in to the app now. Let's say that for some reason, if you check out that branch and run the dev, stuff here, then, you'll get a nice, new pie chart.
You click on that and it will show you a percent of your completed and incomplete tasks, which is kind of fun. And this is all using react-d3, two enormous libraries. So, if I am on this, actually, if I look at my Network tab here, I refresh the page.
I'm not using the the chart. Maybe, I'm just coming here to check off a quick to do. I don't care about that chart. I'm still loading 2.1 MB. This is in development, but in production, that'll still be of considerable size, mostly, because of D3 and React. And so, I want to load this stuff as late as possible, only when the user navigates to those, to that graph.
So, any questions about the why behind me on code splitting? Makes sense? Okay, so, I should mention also, this is one of the features that I actually, I think, I'd mentioned earlier, that you probably would have a hard time doing with Angular one. Because Angular one needs all modules defined up front.
And all the components and everything needs to be defined up front. And implementing code splitting is not trivial with Angular one. I spent a week on it and it failed. So, you have to structure your app in a really specific way. Something like Backbone or React is a lot easier.
Daniel U asked, Kent, can you give some advice on speeding up Webpack with pre-fetched plugin or DLLs? Do you use any of these? I actually don't use the prefetched plugin or DLLs. We will look into some sort of alternative solutions a little bit later. And Henry is asking, is this features the same as critical CSS path rendering?
So, it's better to just put the stuff that's important in the head. So, it is a little bit different. You could potentially accomplish the same thing. Once we get a little bit further along, you could use Webpack to accomplish a critical CSS stuff. And you actually could use code splitting to do that as well.
Yeah, actually, and I think about it. Yeah, you could totally use code splitting to just load the critical stuff first, and then, load the rest of your app later. And Webpack, the answer is always yes with Webpack.
Kent C Dodds: It's always yes.