What TypeScript is not: runtime, performance and other myths

A few beliefs about TypeScript are common, confidently stated, and wrong. Clearing them up now saves you from bad decisions later — and from arguments with people who half-understand the tool. Each myth below follows directly from how the checker actually works.

Myth 1: "TypeScript makes your code faster"

It does not. TypeScript types are erased before your code runs (the last lesson), so the running program is plain JavaScript — exactly as fast, and exactly as slow, as the JavaScript you would have written. There is no runtime type information to optimise with, and no "typed fast path".

Where the confusion comes from: TypeScript can help you write faster code by making refactoring safe, and the compiler itself does work — but the shipped program has no performance advantage from types. If someone tells you to adopt TypeScript "for performance", they have misunderstood it. Adopt it for correctness and maintainability; those are its real gifts.

Myth 2: "TypeScript checks types at runtime, so my data is safe"

It does not, and this is the dangerous one. Because types are erased, TypeScript performs no runtime validation whatsoever. This annotation is a promise you are making to the compiler, not a check:

const response = await fetch("/api/user");
const user: { name: string; age: number } = await response.json();
console.log(user.age.toFixed());   // TypeScript trusts you — but the API might send anything

TypeScript believes user has that shape. At runtime, response.json() returns whatever the server actually sent — which might be missing age, or have it as a string, or be an error object. If the data does not match, user.age.toFixed() crashes at runtime, and TypeScript never warned you, because there is no TypeScript at runtime to warn you.

The correct mental model: TypeScript checks the code you wrote; it does not check the data that flows in from outside. For external data — API responses, JSON.parse, form input, environment variables — you must validate at runtime with actual code (a library like Zod, or hand-written checks), and only then tell TypeScript the shape. The real-projects module covers this properly. For now, internalise: a type annotation on external data is a hope, not a guarantee.

Myth 3: "TypeScript is a different language you have to learn from scratch"

It is not. TypeScript is JavaScript plus a type layer. Every valid JavaScript program is a valid TypeScript program (you may get type warnings, but it runs). You are not throwing away your JavaScript knowledge — you are adding annotations to it. If you know JavaScript, you already know 95% of TypeScript; this course teaches the 5% that is the type system. (That is exactly why the prerequisite is "comfortable JavaScript" — TypeScript assumes it and builds on it.)

Myth 4: "Strict typing everywhere, any is never acceptable"

Nuance required. any — the escape hatch that turns off type checking for a value — is genuinely overused, and a codebase full of any gets none of TypeScript's benefits (the best-practices module is firm about this). But "never use any" as an absolute is also wrong: there are moments — a gradual migration, a genuinely dynamic value, a third-party type that is wrong — where a deliberate, localised, commented any (or better, unknown) is the pragmatic choice. The skill is not "never any"; it is "reach for it rarely, deliberately, and never as a way to make an error message go away". The judgement, not the absolute, is what marks experience.

Myth 5: "TypeScript catches all your bugs"

It catches a category of bugs — type and shape errors — not all bugs. `total(a, b) { return a

• b }when you meant+` type-checks perfectly; both are numbers. An off-by-one, a wrong business rule, a race condition — TypeScript sees none of these, because they are not type errors. TypeScript is a powerful complement to testing, not a replacement for it. A codebase with great types and no tests is still under-tested. The two catch different things, and you want both.

Myth 6: "You have to annotate everything"

You do not, and you should not. TypeScript's inference means you annotate the boundaries — function parameters, return types of public functions, external data — and let it infer the rest. Annotating every local variable (const x: number = 5) is noise; TypeScript already knows x is a number. Over-annotation is a beginner habit that makes code harder to read, not safer. The inference lesson teaches where annotation earns its place and where it is just clutter.

The mental model to keep

Strip away the myths and TypeScript is exactly this: a static analysis tool that reads your JavaScript, checks that the types line up before the code runs, and then gets out of the way. It is not a runtime feature, not a performance tool, not a new language, not a bug-elimination guarantee, and not a demand to annotate everything. It is a checker that trades a little writing effort for a lot of caught mistakes — no more, no less. Holding that accurate model will keep you from both over-trusting it (thinking your data is validated) and under-using it (drowning in any).

Check your work

Does TypeScript make code faster? No — types are erased, so the running JS is exactly as fast as plain JS.

Does it validate data at runtime? No — it performs no runtime checks; an annotation on external data is a promise, not a guarantee. Validate external data with real code.

Is it a new language? No — it is JavaScript plus a type layer; valid JS is valid TS.

Is any always forbidden? No — overused, yes, but a deliberate, localised, commented any/ unknown is sometimes right; the skill is judgement, not an absolute.

Does it catch all bugs? No — only type and shape errors; logic bugs, off-by-ones and races need tests. TypeScript complements testing, not replaces it.

Must you annotate everything? No — annotate boundaries, let inference handle the rest; over-annotation is clutter.

The accurate mental model. A static analysis tool that checks types before the code runs, then erases them and gets out of the way.

Practice

1. Compile a typed function and confirm the emitted JS has no types — so no runtime speed difference.
2. Annotate an API response with a shape the server does not send, run it, and watch it crash at runtime with no TypeScript warning. This is the most important myth to feel, not just read.
3. Take a plain JavaScript file, rename it .ts, and confirm it still runs (JS is valid TS).
4. Write a total that subtracts when it should add. Confirm it type-checks. Note that only a test catches it.
5. Over-annotate a function (a type on every local variable) and then remove the unnecessary ones. Decide which reads better.
6. For each myth, write the one-sentence reason it is false, tracing back to type erasure or inference.

Official documentation

• TypeScript — TypeScript for JavaScript Programmers — Positioned as JS plus types, clearing several myths.
• TypeScript — The any type — What any really does, and its cost.
• Zod — The standard way to actually validate external data at runtime (real-projects module).

Next: setting up a TypeScript project you can actually run.