What is TypeScript and why use it over JavaScript?

Q: What is TypeScript and why use it over JavaScript?

**Target Audience:** Beginners who know some JavaScript and keep hearing "just use TypeScript". **Difficulty:** Easy **TypeScript version:** Compiler behaviour checked with TypeScript 5.4.5 (`tsc --strict`); release history checked against the sources linked inline. > **How to read this doc:** Every idea is explained in plain language first, then tagged with `📌 Interview term:` so you also learn the exact words an interviewer expects. Every compiler message and every output shown was produced by actually running the code; the **Verified** section quotes it in full. ## 1. Why This Even Matters — A Story First Picture a big kitchen. JavaScript is a cook who never reads the labels on the jars: hand them salt instead of sugar and they will happily bake the cake, and you find out when someone takes a bite. TypeScript is a kitchen where every jar is labelled and a sous-chef checks each recipe **before** cooking starts: "this step asks for sugar but you reached for the salt jar". The cook

The problem

Question presented to candidate: "Your team is starting a new project and someone asks why we would use TypeScript instead of plain JavaScript. What is TypeScript, what does it actually give us, and what does it cost?"

What a strong answer should cover:

TypeScript is JavaScript plus a static type system: tsc checks types before the code runs, then erases them and emits plain JavaScript
Concrete bugs it catches that JavaScript runs anyway: property typos (NaN), wrong arguments, missing fields, possibly-undefined values
Type erasure: no run-time cost and no run-time checking, so data at trust boundaries (JSON, network) still needs validation
Tooling and refactoring benefits: autocomplete, safe renames, signatures as documentation; structural typing and gradual adoption
Honest costs: a build or check step (Node.js type stripping does not type-check), learning curve, false confidence from any and as, and the fact that plain tsc still emits on errors unless noEmitOnError is set

Code / implementation expected: Optional — a small typed function showing an error JavaScript would only reveal at run time.

typescript
basics

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Beginners who know some JavaScript and keep hearing "just use TypeScript". Difficulty: Easy TypeScript version: Compiler behaviour checked with TypeScript 5.4.5 (tsc --strict); release history checked against the sources linked inline.

How to read this doc: Every idea is explained in plain language first, then tagged with 📌 Interview term: so you also learn the exact words an interviewer expects. Every compiler message and every output shown was produced by actually running the code; the Verified section quotes it in full.

1. Why This Even Matters — A Story First

Picture a big kitchen. JavaScript is a cook who never reads the labels on the jars: hand them salt instead of sugar and they will happily bake the cake, and you find out when someone takes a bite. TypeScript is a kitchen where every jar is labelled and a sous-chef checks each rec

The solution is hidden so you can try first

10 min read · 10 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

TypeScriptThe bugs TypeScript catches that JavaScript runs anyway

Practice

TypeScriptTypes are erased: only a run-time check protects you

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.