Bundlers, transpilers, and runtimes

A runtime is the program that executes JavaScript. A browser has one. Node has one. This page has a third: a small engine compiled to WebAssembly, which is why your exercises run without a server. Same language, three different environments.

The distinction that matters is between the language and its surroundings. The language gives you values, functions, objects, classes - everything modules 1 to 9 covered - and it is the same everywhere. The surroundings are whatever else that particular runtime chooses to provide: a browser adds document and fetch, Node adds a file system and process, and the engine on this page adds almost nothing, which is exactly why it is safe to run a stranger's code in.

So "does JavaScript have X" is usually the wrong question. The right one is "does the runtime I am targeting have X". The second worked example below asks this page's runtime that question directly, and the answers are worth looking at: JSON and Promise exist because they are part of the language; setTimeout, fetch and document do not exist at all, because no host is providing them here.

Around the runtime sits a toolchain: a formatter, a linter, a type checker, a test runner, a transpiler, a bundler, a minifier. MDN's overview of client-side tooling groups them usefully into a safety net you use while writing, transformation tools that change your code before it ships, and post-development tools for testing and deployment.

Here is the mental model that makes the whole category tractable: with one exception, none of these tools changes what your program MEANS. They take source in and give source out, and the output is supposed to behave identically. A formatter changes whitespace. A minifier changes names and whitespace. A transpiler changes syntax. If any of them changes behaviour, that is a bug in the tool, not a feature.

The exception is the polyfill, which genuinely does add something that was not there. Keeping that one clearly separate from the others is most of what this lesson is for.

A transpiler - Babel is the best-known, and TypeScript and SWC do the same job among others - reads modern JavaScript and writes older JavaScript that behaves the same. Arrow functions become function expressions. Template literals become string concatenation. Class syntax becomes functions and prototypes. The point is that you get to write today's language and still run on an environment that only understands an older one.

The first worked example shows the transformation by hand: the modern version and the transpiled-looking version sit side by side, and the last line checks that they produce the same answer. That is the whole promise of a transpiler in one line of output.

What a transpiler cannot do is invent a capability the runtime does not have. There is no older syntax that means fetch, because fetch is not syntax - it is a function the environment either provides or does not. Rewriting your arrow functions will not conjure it. This is the single most useful distinction in this lesson, and the next section is about the tool that does address it.

A polyfill is ordinary JavaScript that implements a missing feature using whatever the runtime does have, and installs it under the standard name so the rest of your code cannot tell the difference. If an old browser lacks a method, a polyfill defines one that behaves the same way.

The mistake to avoid is expecting your build setup to handle both cases with one switch. Say your code uses a syntax feature and a newer built-in method. The transpiler rewrites the syntax and, quite correctly, leaves the method call exactly as it was - it is a normal function call, and there is nothing to rewrite. On an old runtime the syntax now works and the method is still undefined. The symptom is a build that succeeds and a page that throws "is not a function" on a device you do not own.

The rule to carry: syntax is a transpiler's job, missing capability is a polyfill's job, and knowing which of the two you are relying on is your job. A polyfill also has a cost the transpiler does not - it is real code, shipped to every user, whether they needed it or not.

You have split your program into two hundred files, which is good for you and bad for a browser, which would have to request them all. A bundler - Vite, webpack, Rollup, esbuild - starts at your entry file, follows every import to build the graph of what depends on what, and writes out a smaller number of files containing the same code.

Along the way it does the optimisations MDN's overview mentions. Tree shaking removes exported code that nothing imports, so a library with fifty functions costs you only the ones you used. Minification strips whitespace and shortens local names, which changes nothing about behaviour and a great deal about download size. Source maps are how the shortened result can still be debugged: a side file that maps the built code back to the lines you wrote.

Now the payoff for lesson one's rule about imports living at the top level and naming a literal string. That restriction is what lets the bundler read the graph WITHOUT running your program. MDN's definition of tree shaking says it relies on the import and export statements to work out what is used. Hide an import behind a variable or a condition and you have hidden it from the tool as well.

Less than the industry's noise level suggests. A small project served to modern browsers can use ES modules directly, with no build step at all. Every browser in current use understands import and export.

The tools earn their place when a specific problem appears: you need to support an environment older than your syntax (transpiler), your page makes too many requests or ships too much unused library code (bundler), or your users are on runtimes missing something you depend on (polyfill). Adding a toolchain before you have the problem it solves is how projects end up with configuration nobody understands.

What you should be able to do after this lesson is read a project's setup and say what each piece is for - which is the module's stated goal, and the difference between being able to work in an unfamiliar repository and being locked out of it.

The runtime executes your code and decides what exists beyond the language itself - browser, Node and this page's engine all differ. Everything else in the toolchain transforms source into equivalent source: a transpiler rewrites modern syntax into older syntax, a minifier shortens, a bundler follows the import graph and emits fewer files while tree shaking away exports nobody imports. None of them adds a capability; only a polyfill does that, and it costs real bytes. Tree shaking works because imports are static, which is why they must sit at the top level and name a literal string.