Why types, deeply

Types are a proof, not a hint

The shallow pitch for TypeScript is “autocomplete and red squiggles.” That undersells it. A type annotation is a claim about every value that will ever flow through a position at runtime, and the type checker is a proof engine that either confirms the claim holds on every path or hands you a concrete counterexample — the exact line where a value of the wrong shape can arrive.

function totalCents(items: { priceCents: number }[]): number {
  return items.reduce((sum, it) => sum + it.priceCents, 0);
}

totalCents([{ priceCents: 100 }, { priceCents: 250 }]);
// returns 350

totalCents([{ price: 100 }]);
// Error: Object literal may only specify known properties, and
// 'price' does not exist in type '{ priceCents: number; }'.

The second call never runs. The checker rejected it because the value’s shape contradicts the function’s contract. You did not write a test for “what if someone passes price instead of priceCents” — the type system covered that case, and every other shape mismatch, exhaustively.

The refactor payoff: every stale call site lights up

This is where types earn their keep on a real codebase. Change a contract and the checker enumerates every place that no longer satisfies it.

// before
function track(event: string) { /* ... */ }
track("checkout");

// after: you make the second arg required
function track(event: string, props: Record<string, unknown>) { /* ... */ }

track("checkout");
// Error: Expected 2 arguments, but got 1.
//        An argument for 'props' was not provided.

In JavaScript this is a silent landmine — props is undefined, and the bug surfaces only on the code path that reads it, possibly in production. In TypeScript the incomplete refactor is a compile error at every missed call site simultaneously. The checker is doing a whole-program search you would otherwise do by hand and grep.

Types erase: they are gone before the code runs

Here is the fact that reframes everything. TypeScript types have zero runtime representation. The compiler checks them, then strips them out. The JavaScript that actually executes has no idea types ever existed.

// input.ts
function greet(name: string): string {
  return `Hello, ${name}`;
}
const x: number = 41 + 1;

// emitted output.js — annotations are gone
function greet(name) {
  return `Hello, ${name}`;
}
const x = 41 + 1;

The : string, the : number, the return annotation — all erased. This is type erasure, and it has a hard consequence: types cannot validate runtime data. A type only constrains values the compiler can see at build time. The instant a value crosses a boundary the compiler cannot see — a fetch() response, JSON.parse, a form body, process.env — the type is an assumption, not a guarantee.

const res = await fetch("/api/user");
const user: { id: string; name: string } = await res.json();
//    ^? const user: { id: string; name: string }
user.name.toUpperCase();
// Compiles fine. But res.json() is typed `any` (well, `Promise<any>`),
// so this annotation is a PROMISE YOU made to the compiler, not a fact.
// If the server returns { id: 7, name: null }, this throws at runtime.

The annotation says “trust me, this is the shape.” The compiler believes you. If the wire data disagrees, the type bought you nothing. Real systems close this gap with a runtime validator at the boundary — and that is exactly what lesson 08’s zod material is about: re-establishing, at runtime, the contract the type system assumes statically.

The honest cost: any, structural escape hatches, and unsoundness

A green compile is not a correctness proof. TypeScript is deliberately gradual and unsound in specific, documented places, so you can adopt it incrementally and model real JavaScript.

const data: any = JSON.parse(localStorage.getItem("cart")!);
data.foo.bar.baz();          // no error — `any` disables all checking
data.totalCents.toFixed(2);  // no error — and may explode at runtime

any is a hole in the proof. Any value flowing through an any is exempt from checking and can re-enter typed code as a lie. Other documented escape hatches that produce a green compile over code that can still crash:

const el = document.querySelector(".btn") as HTMLButtonElement;
//                                        ^ assertion: you override the checker
el.disabled = true;          // throws if the element wasn't found (el is actually null)

const arr: number[] = [1, 2, 3];
const n = arr[10];
//    ^? number   <-- LIES. n is `undefined` at runtime (unless noUncheckedIndexedAccess)

These are not bugs in TypeScript; they are the price of a type system pragmatic enough to wrap a 30-year-old dynamic language. When you see any, as, or an unguarded index access in a code review, treat it as a place where the proof has a deliberate gap — and budget a runtime check there accordingly.