Challenge 2: The Real Difference Between Tree Shaking and Code Splitting — Possible Solution ==================================================================== WHY THEY'RE OFTEN CONFLATED ------------------------------ Both techniques do, in a loose sense, make what a user's browser actually has to download smaller — so it's easy to lump them together under a vague "makes the bundle smaller" label. But per this chapter's own table, they answer genuinely different questions about the code involved. WHAT TREE SHAKING ANSWERS ------------------------------ Per this chapter's own table, tree shaking answers: "Is this code used ANYWHERE AT ALL?" It operates on code that is, by determination, NEVER used by the application in any circumstance — per this chapter's own five-function example, formatDate/debounce/throttle aren't "used later" or "used under some condition" — they are simply never imported by anything reachable from the entry point at all, so they are removed from the bundle entirely and permanently. WHAT CODE SPLITTING ANSWERS ------------------------------ Per this chapter's own table, code splitting answers a completely different question: "Is this code needed RIGHT NOW?" Code handled by code splitting (per the chapter's own settings-panel example) IS genuinely used by the application — a real feature a real user might reach — but not necessarily on the very first page load. Code splitting doesn't remove this code from the application at all; it just defers WHEN it gets downloaded, fetching it later, on demand, rather than bundling it into the initial payload every user pays for up front. THE CORE DISTINCTION ------------------------------ Tree shaking permanently discards code because it's genuinely dead — truly unused, full stop. Code splitting keeps code that's genuinely needed, but changes its DELIVERY TIMING rather than its inclusion. One is about existence ("does this code have any reason to exist in the shipped app at all?"); the other is about scheduling ("when should the browser actually fetch this code it will eventually need?"). WHY THIS WORKS AS AN ANSWER ------------------------------ It states each technique's own specific question using the chapter's own table, and explains the underlying conceptual difference (removal of genuinely dead code vs. deferred delivery of genuinely needed code) rather than treating both as interchangeable "size reduction" tricks.