Kent C Dodds: Let's talk about Commons Chunking here. So again we're trying to optimize the results of our web pack build, all of our bundles, to be as small as possible but also make it so that the browser can cash the assets for as long as possible. So say you have two files and one of them is, so the user loads both of the files and then you change only one of them, now the user only needs to load that one file.
The other one is cached, right? So if you have some code that doesn't change very frequently this would be a really good candidate for putting it in the Commons Chunk, so that like any time you make changes to this other code that does change more frequently people don't have to re-download that.
And so the browser has it in its cache and it loads much faster. So that's the idea behind behind Commons Chunking. Another kind of, to kind of conceptualize it, you can have multiple apps that use the same common files, like lodash would be a great example. I use lodash for every example.
I should be more creative. jQuery, or React, or D3 some of these bigger things and vendor files go really well as a Commons Chunk. So then here's all the like, this is the bundle for app one, two, three, and four and those things are specific to these these different apps or these different pages.
Then they go to app two, they load the app two code but because they already went to app one they don't need to re-download that. The alternative of course being that app one itself has all of app one's code as well as all this common stuff and that's kind of what we have right now.
As if we had multiple apps or something then we would like all of the all that stuff would be bundled together into each individual app and so they'd have to download that much for every single app that they go to. So this is a pretty common problem, and I'm pretty certain like I can't think of a single type of application where this wouldn't help.
Yeah, pretty much no application this could be beneficial.