From JavaScript to TypeScript

"TypeScript is JavaScript that scales." — the TypeScript project's original tagline

Welcome to Volume 2. You finished Volume 1 having learned JavaScript end to end — the language, its runtime, its quirks, and its libraries — and the final chapter there made the case for why a language like TypeScript had to exist: JavaScript's freedom is glorious until a codebase grows, a team grows, or a user.emial typo ships to production and nobody finds out until a customer does. This volume is the answer. Over the next nine parts you will go from "I've heard of types" to genuinely fluent — able to model a domain in types, read a gnarly generic signature at a glance, and reach for TypeScript the way you already reach for const. We begin, sensibly, by getting you productive: what TypeScript actually is, how to run it, and the tight feedback loop that will change how you write code.

Core Concepts

TypeScript is a typed superset of JavaScript. Read that phrase precisely, because both halves matter. Superset means every valid JavaScript program is already a valid TypeScript program — there is no rewrite, no new syntax to learn before you can start. Typed means TypeScript adds one thing on top: optional type annotations, small notes that describe the shape of your data, which a compiler checks before your code ever runs. Catch the bug at author time, not at 3am from a pager.

The third fact is the one that surprises people, and it is the key to the whole design: types are erased. TypeScript is not a runtime. When you build, the compiler checks your annotations, then throws them away, emitting ordinary JavaScript — the same JavaScript you'd have written by hand. There is no TypeScript engine in the browser or in Node. The types exist to help you and your tools; at runtime they simply are not there. Zero runtime cost, zero runtime magic.

Setting up the toolchain

TypeScript is a package you install into your project. It ships one binary you'll use constantly — tsc, the TypeScript compiler.

npm i -D typescript      # add the compiler as a dev dependency
npx tsc --init           # generate a tsconfig.json
npx tsc                  # type-check + compile once, per tsconfig
npx tsc --watch          # re-check on every save (great during dev)

tsc --init writes a tsconfig.json — the project's control panel: which files to include, which JavaScript version to emit, how strict to be. A minimal, modern one:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "strict": true,
    "outDir": "dist",
    "rootDir": "src"
  }
}

The single most important line there is "strict": true. It switches on the full family of checks — no implicit any, strict null handling, and more — and it is the setting this entire volume assumes. Turn it on from day one; retrofitting strictness onto a large loose codebase is a genuinely miserable job, and you never want to teach yourself the sloppy version first.

You don't always need a separate build step to run TypeScript, though. Tools like tsx and ts-node compile-and-run in one motion, which is perfect for scripts and quick experiments:

npx tsx src/main.ts      # run a .ts file directly, no visible build

The dev loop: two places the same check runs

The check that makes TypeScript feel magical runs in two places, and both matter. In your editor, a background language server re-type-checks as you type and draws red squiggles under mistakes — you learn a call was wrong while your fingers are still on it. Then in CI, tsc --noEmit runs the exact same check on every push, so a mistake that slips past one developer's editor can't merge. Same compiler, same rules, two safety nets: one for speed of feedback, one for the guarantee. The error is caught at author time, not at run time — that shift is the entire value proposition.

All JavaScript is already TypeScript

Because TS is a superset, adoption can be a single command: rename app.js to app.ts and you have valid TypeScript. Nothing else is required. TypeScript will immediately start inferring types for you — it sees const count = 0 and knows count is a number without you saying so — and it will only complain where it can prove something is off. You then add explicit annotations where they earn their keep: function boundaries, tricky data shapes, anywhere a reader (including future-you) benefits from the intent being written down.

Your first types

An annotation is a colon and a type. Here it is on a variable and, in the next block, on a function. Watch a wrong assignment turn into a compile error you can see in the editor panel:

That red mark appears at compile time. Now a function, with the required deliberate mistake — passing a string where a number is expected — followed by the corrected call that actually logs a result:

Notice something important about that double("21") line: the type panel shows the ✗, but the emitted JavaScript still runs — TypeScript reports the problem, it doesn't stop you at gunpoint. In a real project, tsc in CI is what turns that report into a hard gate. The type system is advisory to the runtime and mandatory to your pipeline.

Type erasure, made concrete

The best way to believe "erased at compile time" is to see the output. Here is a small TypeScript file:

function greet(name: string): string {
  return `Hi, ${name}`;
}

const user: string = "Ada";
console.log(greet(user));

And here is the JavaScript tsc actually emits from it — the exact same logic with every annotation gone:

function greet(name) {
  return `Hi, ${name}`;
}

const user = "Ada";
console.log(greet(user));

The : string annotations, the return type — all vanished. What ships is lean JavaScript. This is why TypeScript adds no runtime overhead and cannot enforce types at runtime: by the time the code executes, there are no types left to check. Remember this the first time you're tempted to trust a type to validate data coming from a network — that's a job for runtime validation, because the type is long gone.

Common Mistakes

• Expecting types at runtime. Types are erased — you cannot if (x instanceof MyType) on an interface, and a string annotation won't stop bad JSON from arriving. Validate untrusted input with real runtime code (or a library like Zod).
• Leaving strict off "for now." Loose mode lets any creep everywhere and hides exactly the bugs you adopted TypeScript to catch. Retrofitting strictness onto a big loose codebase is the expensive path.
• Annotating everything. Writing const n: number = 0 is redundant — inference already knows. Reserve explicit types for function signatures and genuinely ambiguous spots; let the compiler carry the rest.
• Confusing tsc with a bundler or a runtime. tsc type-checks and emits JS; it does not bundle, minify, or run your server. Those are separate tools that sit alongside it.
• Thinking a red squiggle blocks the run. By default the emitted JS still executes. The gate is tsc failing in CI — wire that up, or errors merge anyway.

Interview Corner

Chapter Summary

• TypeScript is a typed superset of JavaScript: all valid JS is valid TS, plus optional type annotations.
• The compiler tsc checks types before runtime, then erases them, emitting plain JavaScript with zero runtime cost.
• Set up with npm i -D typescript, tsc --init (a tsconfig.json — keep "strict": true), then tsc, tsc --watch, or run directly with tsx/ts-node.
• The dev loop runs the same check twice: editor squiggles at author time, tsc in CI as the merge gate.
• Adoption is incremental — rename .js to .ts; inference does a lot, and you annotate where it helps (boundaries first).
• Because types are erased, they can't validate runtime data — trust boundaries still need real runtime checks.

Editorial reflection — the temptation is to treat TypeScript as JavaScript with extra ceremony — annotations to appease a compiler. That framing gets it backwards. The types aren't the tax; they're the design tool. Writing the shape of your data down forces you to decide what your data is before you build on it, and a compiler that holds you to that decision is not a nag but a collaborator with perfect memory. You already know JavaScript. This volume is about learning to think in shapes — and the rest of the language follows from there.