What TypeScript Is & Why Types Matter

TypeScript is JavaScript with one addition: a type layer that reads your code before it runs and refuses to build it if the pieces don't fit. That's the entire product — and it's the reason most professional JavaScript today is written as TypeScript. This lesson shows you what a type actually is, which bugs the checker catches for you, and the one fact everything else in this course rests on.

What a type actually is

A type is a set of allowed values plus the operations that are safe on them. number is every numeric value and the things numbers can do — arithmetic, .toFixed(). string is every piece of text and its operations — .toUpperCase(), .trim(). That's it. No magic.

Once you see types as sets, type errors stop being scoldings and become simple set logic: "hello".toFixed(2) is an error because .toFixed isn't in the set of things strings can do. You already think this way — TypeScript just writes it down and holds you to it.

const price: number = 19.99;
const label: string = "Total";
 
console.log(label + ": " + price.toFixed(2));

→ Total: 19.99 — the annotations after the colons (: number, : string) are the type layer. Everything else is plain JavaScript.

The bugs types catch — and the bugs they can't

Here's real JavaScript that runs without a complaint and is still wrong:

const user = { name: "Ada", plan: "pro" };
console.log(user.nmae); // typo — JavaScript would print undefined

→ error TS2339: Property 'nmae' does not exist on type '{ name: string; plan: string; }'.

Plain JavaScript would happily print undefined and let the bug ride to production. TypeScript catches it before the code runs. Whole categories of bugs die this way: typos, wrong argument order, forgetting a value can be missing, calling methods that don't exist on that kind of value.

Be equally clear about what types can't catch: wrong math that's the right shape (price * 1.2 when you meant * 1.02), business logic errors, and — the big one — wrong data arriving from outside at runtime. A type says "this should be a number"; it can't stop a server from sending you a string. Lesson 13.1 is devoted to that boundary.

Compile time vs. run time

That callout is the course's master key, so let's name the two worlds properly:

• Compile time — you (and the checker) are reading the code. Types exist here. Errors here are found, not suffered.
• Run time — the program is executing with real data. Types have been erased. Errors here are crashes and wrong answers.

Languages like Python check types while the program runs (dynamic typing — you learn about a wrong type when that line executes, hopefully in a test). TypeScript checks before it runs (static typing — you learn about it in your editor, seconds after typing it). The trade: you spend a little effort declaring intent, and the machine verifies millions of code paths you'd never manually test.

Try it — the checker is live on this page

This playground runs the real TypeScript compiler in your browser (it loads once, then it's instant). Hit Run: the code type-checks first, and only then does the erased JavaScript execute — exactly how tsc behaves with noEmitOnError. Then follow the comment at the bottom.

When you uncomment that last line, nothing runs at all — the checker rejects "premium" because the Plan type is the two-value set "free" | "pro", and "premium" isn't in it. That's the workflow this whole course drills: break it, read the error, fix it, run. The error messages are the real ones you'll see at work; learning to read them calmly is a superpower we start building now.

Where this course takes you

Types-as-sets scales astonishingly far. In Part I you'll narrow union types with ordinary if statements and model app states that make invalid data unrepresentable. Part II gives you generics — functions that preserve whatever type they're given. Part III teaches type-level programming: types computed from other types, the trick behind libraries whose autocomplete feels psychic. And Parts IV–VI turn it professional: async, testing, publishing typed packages, and reading the gnarliest types in other people's code without flinching.

Next up: where this language came from, who runs it, and why the compiler itself is about to get ten times faster.