Why TypeScript exists
The late-runtime-error problem, a short verified timeline, and who uses it.
JavaScript finds your typos at runtime, in production, in front of users. TypeScript moves that moment earlier: you annotate the shapes you meant, the checker compares every use against them, and wrong code fails in your editor instead of on someone's screen.
The problem it solves
Dynamic code trusts every caller. A price arrives as the string "12",
a refactor renames userName to name in four of five places, and
nothing complains until the page renders NaN or crashes. Interviewers
love this framing because it is honest: types do not make code correct,
they make whole classes of mistakes impossible to ignore.
Seen in: Visual Studio Code's core is fully implemented in TypeScript (source code organization, checked 2026); Angular is written in TypeScript and uses it as its primary language (TypeScript Handbook: Angular); the TypeScript compiler itself was self-hosted TypeScript until the 7.0 native port (see the timeline below).
A short verified timeline
Microsoft unveiled TypeScript 0.8 on October 1, 2012, led by Anders
Hejlsberg, as a typed superset of JavaScript for large applications
(ten years of TypeScript).
TypeScript 1.0 followed in April 2014 with a stability promise for type
definition files
(announcement).
The team announced a native Go port of the compiler in March 2025, and
TypeScript 7.0 shipped it on July 8, 2026 — roughly ten times faster,
with the typescript package now carrying the native compiler and API
consumers staying on the @typescript/typescript6 compatibility package
(announcing TypeScript 7.0).
The idea in one paragraph
Every JavaScript program is already a TypeScript program: add annotations where they pay off, and the compiler erases them on emit. Nothing you write in types survives to runtime — no checks, no overhead, no behavior change. That erasure is the whole deal, and the next page shows exactly where the boundary lies.
Interview questions
What is TypeScript?basic
TypeScript is a typed superset of JavaScript maintained alongside the typescript compiler package. You write .ts files with optional type annotations, then the compiler checks them and emits plain .js you can run anywhere JavaScript runs. Valid JavaScript is usually valid TypeScript, so you can adopt it gradually. Think of it as JavaScript plus a static checker that catches mistakes before your code runs.
Interviewers also ask
- Where does type checking happen — runtime or before?
Why would you choose TypeScript over plain JavaScript?basic
You get earlier feedback on the mistakes JavaScript hides until runtime: misspelled properties, wrong argument shapes, and forgotten null cases. Types also act as living documentation, so you spend less time guessing what a function expects. Editors use them for precise autocomplete and safe renames. For teams and long-lived codebases, that means fewer runtime surprises and faster refactors, at the cost of writing and maintaining the annotations.
Interviewers also ask
- What does TypeScript cost you in return?
What changed with TypeScript 7's native compiler?intermediate
TypeScript 7, released July 8 2026, ships a native compiler written in Go inside the typescript package for much faster checking and builds. The native compiler does not offer a programmatic JavaScript API, so tools that called the old API should use the @typescript/typescript6 compatibility package, which provides the tsc6 binary and re-exports the 6.0 API. Everyday tsc command-line usage stays familiar.
Interviewers also ask
- What should a tool author do if they relied on the compiler API?
What kinds of bugs does TypeScript catch for you?basic
It catches shape mismatches: calling a function with the wrong arguments, reading a property that does not exist, or assuming a value is defined when it can be null. It also flags misspelled names and incorrect assignments across files, which plain JavaScript would only reveal at runtime. You still need tests for logic errors, but the compiler removes a whole class of silly wiring mistakes before you even run the code.
Interviewers also ask
- Can TypeScript catch logic errors too?
When does TypeScript check your types?intermediate
It checks statically, before your code runs — when your editor highlights an error or when you run tsc in your build. Nothing about the check survives into the emitted JavaScript. That means a passing check tells you the code was consistent at build time, not that runtime data will match. Data from an API or user input still needs runtime validation, because the compiler cannot see what the network will send.
Interviewers also ask
- Why do you still need runtime validation for API data?
References
Last verified: 2026-10-13.