jargon

Frontend & browser·topic 5 of 13

Modules, bundling and the build

The pipeline that turns a few hundred source files into the handful of files a browser downloads. Everything here is about shipping less code, or about shipping the same code in a way the browser can keep.

Read in order · tick what you already know

  1. 01

    you wrote `import` at the top of the file and the tooling could tell what you used without running anything.

    ES module

  2. 02

    the package only shipped `require` and your bundler could not shake anything out of it.

    CommonJS

  3. 03

    you point one tool at an entry file and it follows every import and writes out a handful of files.

    Bundler

  4. 04

    you imported one helper and the build pulled in a date library you have never used directly.

    Module graph

  5. 05

    you named the one file the build starts from and everything else was found by following its imports.

    Entry point

  6. 06

    the build wrote out eleven numbered JavaScript files and the page only requests three of them.

    Chunk

  7. 07

    you import one function from a library and the other two hundred never reach the bundle.

    Tree shaking

  8. 08

    the branch behind `if (process.env.NODE_ENV !== 'production')` disappeared entirely from the output.

    Dead code elimination

  9. 09

    you added `"sideEffects": false` to the package and the bundle got noticeably smaller.

    Side-effect-free module

  10. 10

    you imported one icon from the package index and the build pulled in every icon it exports.

    Barrel file

  11. 11

    the settings screen's code is not downloaded until someone actually opens the settings screen.

    Code splitting

  12. 12

    you wrote `await import('./editor')` and the bundler quietly turned that line into a separate file.

    Dynamic import

  13. 13

    the chart component loads on first render of the chart, with a fallback shown while it arrives.

    Lazy component

  14. 14

    you split the dependencies into their own file so a change to your code does not invalidate them.

    Vendor chunk

  15. 15

    two copies of the same library ended up in the bundle because two packages asked for different versions.

    Duplicate dependency

  16. 16

    the file is named with a string of hex that changes only when its contents change.

    Content hash

  17. 17

    you deployed a fix and users kept getting the old file until you changed its name.

    Cache busting

  18. 18

    the JavaScript is cached for a year because its name guarantees the contents can never change.

    Immutable caching

  19. 19

    the shipped file is one line, every local variable is a single letter, and the comments are gone.

    Minification

  20. 20

    the error points at line 4200 of a minified file, and the debugger shows you your original source anyway.

    Source map

  21. 21

    you wrote modern syntax and the build rewrote it into something older browsers can parse.

    Transpilation

  22. 22

    you loaded a script that defines the missing method on the global object so the rest of the code can call it.

    Polyfill

  23. 23

    you imported the replacement as a normal function instead of letting it patch the global object.

    Ponyfill

  24. 24

    you narrowed the supported browser list and the output shrank without you deleting any code.

    Build target

  25. 25

    you saved the file and the component updated on screen without losing what you had typed into the form.

    Hot module replacement

  26. 26

    you generated the treemap and found one dependency taking up a third of the bundle.

    Bundle analysis

  27. 27

    one deployed application loads a component from another at runtime, over the network, from its own build.

    Module federation

  28. 28

    three teams each own a section of one page and each deploys their section without the others.

    Micro-frontend

  29. 29

    you told the browser directly what `react` resolves to and skipped the bundler for that import.

    Import map