Kaj sta code splitting in tree shaking?

Question

IT Interview Practice · Accepted Answer

Oba zmanjšata JavaScript, ki ga uporabniki prenesejo. **Code splitting** razbije bundle na kose, naložene po potrebi; **tree shaking** odstrani kodo, ki je nikoli ne uporabiš. Dopolnjujeta se: razdeli *kaj* se naloži, otresi *mrtvo* kodo znotraj vsakega kosa.

## Code splitting

Namesto enega velikega bundla je aplikacija razdeljena tako, da je vsaka pot ali težka funkcionalnost ločen kos, pridobljen le, kadar je potreben:

```js
// Route-based split: the dashboard code isn't downloaded until you visit it
const Dashboard = lazy(() => import("./routes/Dashboard")); // its own chunk

// Component-based split: heavy editor loaded on interaction
button.onclick = async () => {
  const { openEditor } = await import("./editor"); // fetched on click
  openEditor();
};
```

Dinamični `import()` je signal — bundler na tej meji izda ločeno datoteko.

## Tree shaking

Bundler statično analizira `import`/`export` ES modulov in izpusti izvoze, na katere se nič ne sklicuje. Deluje le z **ESM** (statičen, analizabilen) — ne s CommonJS `require`:

```js
import { debounce } from "utils"; // only debounce is kept; throttle, etc. are shaken out
```

Opira se na `"sideEffects": false` v `package.json` in uvoze posameznih funkcij; barrel datoteke ali moduli s stranskimi učinki ga lahko izničijo.

## Kompromisi

- Prekomerno razdeljevanje → mnogo drobnih zahtev in slapov (waterfalls); združi sorodno kodo.
- Tree shaking je krhek — napačno označen stranski učinek obdrži mrtvo kodo.

## Zakaj je to pomembno

To sta dva vzvoda za »pošlji manj JS«. Spraševalci želijo, da veš, da code splitting odloča *kaj se naloži in kdaj*, tree shaking pa odloča *kaj sploh je noter*, in da je tree shaking odvisen od statičnega ESM — podrobnost, ki loči tiste, ki so bundle dejansko uglaševali, od tistih, ki so o tem le brali.

Code splitting

Tree shaking

Kompromisi

Zakaj je to pomembno

Povezana vprašanja