Sean T. Larkin
Sep 9, 2018 · 1 min read

Hey David,

This is a nice article but as one of the maintainers of webpack I’d like to be authoritative with this criticism. Mainly because it’s being marketed as “correct” but instead, a majority of the reasoning and advice is incorrect.

  1. Code-splitting is a must/always technique every app should be employing. In-fact it should take precedence over caching techniques. But why? First, the main cost of any pages' load time is the _size_ of the JavaScript you ship. Caching only optimizes the networking layer consistently. For example, no matter how fast the file comes from the network, the browser still pays the 4mb parse, eval, and execute cost everytime. (Some browsers have bytecode caching but it should absolutely not be relied on because it varies so different across browsers, sessions, etc.)
  2. We removed the CommonsChunkPlugin and hid the evolution of it in config for a reason: because only in 90% of cases do you ever need to modify the defaults webpack 4 sets out of the box. So please don’t modify the settings because almost always, you are doing more damage by creating bloated vendor bundles. Check the code coverage tool in Chrome. How much JavaScript is unused from those bundles? It amounts to a large amount (usually 75–90%).

Something I might suggest in the future before you put “100% correct" in your article title is double check with the maintainers of the project to verify and validate it’s correctness. Thanks for taking the time to write your article on behalf of the webpack team.

— Sean

Sean T. Larkin

Written by

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade