What TypeScript actually is
TypeScript doesn't change what your code does at runtime — it's a separate layer that checks your code before it runs, then disappears entirely. Getting that one fact straight is what makes everything else about TypeScript make sense.
4 min read
TypeScript is JavaScript, plus a checker that runs before your code does
function greet(name: string) {
return "Hello, " + name;
}
greet(42); // TypeScript refuses to compile thisEvery valid JavaScript file is already valid TypeScript — TypeScript is a superset of JavaScript, not a different language. What it adds is a type system: annotations like : string that a separate tool, the TypeScript compiler (tsc), reads and checks before your code ever runs. greet(42) never executes here — tsc refuses to produce output at all, catching the mismatch at compile time instead of letting it become a runtime bug (or worse, a runtime bug that doesn't crash, just silently does the wrong thing).
Compilation: TypeScript in, JavaScript out
// greet.ts
function greet(name: string): string {
return "Hello, " + name;
}// greet.js — the actual compiler output
function greet(name) {
return "Hello, " + name;
}Running tsc greet.ts produces greet.js — and notice what's missing: every type annotation is gone. This is the single most important mechanical fact about TypeScript: types are erased completely at compile time. The JavaScript that actually runs, in a browser or on Node, has no idea types ever existed. Nothing about : string survives into the executable output — not a runtime check, not a comment, nothing.
The direct consequence: nothing about types exists at runtime
function processValue(value: string) {
console.log(typeof value); // "string" — this works, but NOT because of the annotation
}Because types vanish at compile time, you can never inspect a TypeScript type at runtime — there's no value.getType(), no way to ask "what type was this parameter declared as." typeof value above works because typeof is a genuine JavaScript operator inspecting the actual runtime value, completely independent of whatever TypeScript annotation was written. This trips up nearly everyone at first: reaching for a TypeScript-only construct (an interface, a type alias) at runtime, expecting it to somehow still be there, gets a "cannot find name" error — interfaces and type aliases are compile-time-only constructs with zero JavaScript equivalent, erased just like the : string annotation was.
Type checking happens on your actual, real, dynamic JavaScript
let value: string = "hello";
value = 42; // Error: Type 'number' is not assignable to type 'string'TypeScript isn't a new syntax bolted onto a different runtime — every JavaScript value still behaves exactly like JavaScript at runtime (numbers are still floats under the hood, null is still weird, this still binds the way it always did). The compiler's entire job is reasoning about whether the shapes and types your code implies are internally consistent, given everything JavaScript itself already does. This is why a .ts file can always be renamed to .js and still run identically once compiled — TypeScript adds a checking layer on top, it doesn't change the underlying language semantics.
Why bother, if the runtime behavior never changes
// Without types — this typo isn't caught until you actually run it
function getUserEmail(user) {
return user.emial; // no error, no warning — silently returns undefined
}
// With types — the same typo is a compile error, before you ever run anything
interface User { email: string; }
function getUserEmail(user: User) {
return user.emial; // Error: Property 'emial' does not exist on type 'User'
}The value isn't runtime behavior — it's catching an entire category of mistake (typos, wrong argument types, calling a method that doesn't exist on a given shape) at the moment you write the code, in your editor, instead of discovering it later when that exact line finally executes with the wrong input. This is the same "catch it before it ships" value a test suite provides, but continuous and immediate — an editor with TypeScript support underlines the mistake as you type, not after you run a test.
Further reading
- TypeScript docs — TypeScript for JavaScript programmers
- TypeScript docs — the TSConfig reference
- TypeScript Playground — write TypeScript and see the compiled JavaScript output side by side.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What happens to TypeScript's type annotations when the compiler produces JavaScript output?
2. Why can't you check a value's TypeScript type at runtime (e.g. inside an if statement while the program is running)?
3. What is the actual value of using TypeScript, given that it doesn't change runtime behavior at all?