Why TypeScript, and How It Runs
BeginnerTypeScript is a checker, not a runtime. It erases to JavaScript and disappears — which explains both what it catches and everything it cannot.
Overview
Coming from Java the instinct is that types are enforced at runtime. In TypeScript they are not: tsc checks your code, then strips every annotation, and what ships is plain JavaScript with no type information at all. That single fact explains most of the surprises — why a value from an API can lie about its type, why you cannot check an interface with instanceof, and why generics have no runtime cost. TypeScript is a very good linter with an excellent type system, and treating it that way keeps your expectations correct.
Erasure
What you write and what runs. Everything type-shaped is gone.
// TypeScript
interface User { id: number; name: string }
function greet(user: User): string {
return `Hi ${user.name}`
}
// Compiled JavaScript — the interface does not exist at runtime
function greet(user) {
return `Hi ${user.name}`
}
// Which means this is impossible:
if (value instanceof User) { } // Error: 'User' only refers to a type
// And this compiles, then explodes at runtime:
const data = await res.json() as User // 'as' is a claim, not a check
data.name.toUpperCase() // undefined if the API changedConfiguration That Matters
A handful of tsconfig flags account for most of the value. strict is the one that matters.
{
"compilerOptions": {
"strict": true, // turn this on; everything below is inside it
// strictNullChecks -> null and undefined are separate types
// noImplicitAny -> untyped parameters are an error
// strictFunctionTypes, strictBindCallApply, ...
"noUncheckedIndexedAccess": true, // arr[0] is T | undefined — accurate
"noUnusedLocals": true,
"target": "ES2022",
"module": "ESNext",
"moduleResolution": "bundler",
"jsx": "preserve",
"skipLibCheck": true, // do not type-check node_modules
"noEmit": true // the bundler emits; tsc only checks
}
}
// Without strictNullChecks, string includes null and undefined,
// and the compiler cannot warn you about the most common crash there is.What It Catches, and What It Does Not
The boundary is the network. Inside your code types hold; at the edge they are a promise nobody verified.
// Caught at compile time
user.emial // typo
user.age + 1 // if age is string
fn(1, 2) // wrong arity
if (user) {} else { user.name } // narrowing violation
// NOT caught — all of these compile and fail at runtime
JSON.parse(text) as User // no validation happens
res.json() as Product[] // the API can return anything
arr[10].name // out of bounds (unless noUncheckedIndexedAccess)
(value as any).anything // 'any' switches checking off
// The fix at the boundary is a runtime validator:
import { z } from 'zod'
const User = z.object({ id: z.number(), name: z.string() })
const user = User.parse(await res.json()) // throws if the shape is wrong
// and 'user' is now correctly typed AND actually verifiedKey Points to Remember
- 1TypeScript checks then erases — the shipped JavaScript contains no type information
- 2Because types are erased you cannot use instanceof on an interface or check a type at runtime
- 3strict: true enables strictNullChecks and noImplicitAny, which is where most of the value lives
- 4"as" is an assertion you make to the compiler, not a check the compiler performs
- 5Data from the network is unverified — use a runtime validator such as Zod at the boundary
Interview Questions
Sign in to ask AriaDoes TypeScript provide any runtime type safety? Explain your answer.
What does strict mode enable, and why does strictNullChecks matter most?
How do you actually guarantee that an API response matches its declared type?
Ask Aria about Why TypeScript, and How It Runs
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.