Transpilation — Babel and the TypeScript Compiler

Course 1 · Ch 4

Two genuinely different jobs that both happen to output plain JavaScript, and how source maps keep debugging possible afterward

build-tooling1-3 previewed babel-loader without explaining what it actually does. This chapter gives transpilation its full treatment — and draws a real, important distinction most developers blur together: Babel's job and the TypeScript compiler's job are not the same kind of work, even though both end in plain JavaScript.

What Transpilation Actually Means

Transpilation converts code from one syntax into a different but comparable syntax — source to source, staying at roughly the same level of abstraction, unlike compiling down to a fundamentally lower-level representation like machine code. Two genuinely different transpilation jobs matter for real projects: converting newer JavaScript syntax into older-browser-compatible JavaScript (Babel's core job), and converting TypeScript into plain JavaScript (the TypeScript compiler's job).

Babel — New JS Syntax, Older Browsers

Babel rewrites modern syntax into an older, equivalent form:

// Written by a developer, using modern syntax
const getName = (user) => user?.profile?.name ?? 'Guest';

// What Babel emits for older browsers
var getName = function (user) {
  var _user$profile;
  var name = user === null || user === undefined ? undefined
    : (_user$profile = user.profile) === null || _user$profile === undefined
    ? undefined : _user$profile.name;
  return name !== null && name !== undefined ? name : 'Guest';
};

Both versions behave identically — the second just avoids syntax (arrow functions, optional chaining, nullish coalescing) an older JavaScript engine wouldn't understand. Babel decides exactly which transformations to apply based on a configured target browser list (@babel/preset-env, checked against a browserslist config) — echoing build-tooling1-3's own plugin-based extensibility model directly.

The TypeScript Compiler (tsc) — A Different Kind of Transform

ts1-1 mentioned tsc in passing. Here's the full picture: TypeScript source carries type annotations that don't exist in JavaScript at all.

function add(a: number, b: number): number {
  return a + b;
}
// tsc emits: function add(a, b) { return a + b; } — types simply stripped

tsc does two genuinely separate things: it type-checks the code, catching type errors before anything ever runs, and it strips the type annotations entirely, emitting plain JavaScript. That's a meaningfully different kind of work than Babel's own syntax-rewriting — Babel has no understanding of TypeScript's type system at all; it can strip type syntax mechanically, but it never actually checks whether the types are used correctly.

This distinction has a real, common practical consequence: because full type-checking is comparatively slow, many real projects run tsc only for type-checking (often as a separate CI or editor-integration step), while relying on a faster tool — Babel, or build-tooling1-6's own esbuild/SWC — purely for the actual transpilation and bundling. Type safety and fast builds, handled by two different tools doing two different jobs.

	Babel	tsc
Transforms	Modern JS syntax → older JS syntax	TypeScript → plain JavaScript
Type-checks?	No — mechanical syntax rewriting only	Yes — its actual core job
Common real-world role	Fast transpilation, often bundler-integrated	Often used only for type-checking, separately from the fast build

Source Maps — Debugging Transformed Code

Once code has been transpiled — and later minified and bundled (build-tooling1-8) — what's actually running in the browser looks nothing like the source a developer wrote. Without help, DevTools would show only that unrecognizable output. A source map is a file mapping every position in the transformed output back to its exact original position in the source, which DevTools read automatically — letting a developer set breakpoints and read stack traces against the original source, even while the transformed version is what's genuinely executing.

Source maps in production are a real trade-off

Shipping source maps publicly means anyone inspecting the deployed site can reconstruct the original, un-minified source — a real business/security consideration, not a hypothetical one. Many production deployments deliberately generate source maps for internal error-tracking tools while never exposing them publicly, or omit them from production builds entirely.

Babel's own speed limits, ahead

build-tooling1-6 explains exactly why esbuild and SWC can do much of Babel's own syntax-transformation job dramatically faster — a real, mechanical reason, not a marketing claim.

Coding Challenges

Challenge 1

Explain the real difference between what Babel does and what tsc does, and explain why a real project might use tsc only for type-checking while relying on a separate, faster tool for the actual transpilation.

📄 View solution

Challenge 2

Explain what specific problem source maps solve for a developer debugging a transpiled and minified bundle in browser DevTools, and explain the real trade-off this chapter names around shipping source maps to production.

📄 View solution

Challenge 3

Using this chapter's own definition of transpilation as "source to source, staying at roughly the same level of abstraction," explain why it's a meaningfully different kind of operation than compiling source code down to real machine code.

📄 View solution

Chapter 4 Quick Reference

Transpilation — source-to-source conversion, staying at a similar level of abstraction (unlike compiling to machine code)
Babel — rewrites modern JS syntax into older-browser-compatible JS, based on a configured browser target list, no type awareness
tsc — type-checks TypeScript AND strips its type annotations, emitting plain JS; a genuinely different kind of work than Babel's
Real projects often split the two jobs: tsc for type-checking only, a faster tool for actual transpilation/bundling
Source maps — map transformed/minified output back to original source positions, letting DevTools debug against the real source
Shipping source maps to production exposes original source code — a real, deliberate trade-off, not an oversight when omitted
Next chapter: Vite — The Modern Dev-Server-First Approach