PHASE 0Beginner ~20 min· topic 1 of 4

Topic 0.1

What TypeScript Is and Why It Exists

In one line

TypeScript is JavaScript plus types: you write down what kind of value each thing holds, and a checker reads your code and points out mistakes before the code ever runs.

Think of it like this

A shape-sorter toy. The square block only fits the square hole. A toddler finds out the moment they try to push a circle into it, not days later when the toy breaks. TypeScript gives your code shaped holes. You say "this function takes a number", and if you try to push text into it, the editor stops you right there, before anyone runs the program.

Words you'll meet

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

JavaScript: The programming language web browsers run. TypeScript is built on top of it.
TypeScript: JavaScript plus types and a checker that finds mistakes before the code runs.
Type: A promise about a value: what kind of thing it is (number, text, an object with certain fields) and what you can do with it.
Runtime: The time when the program is actually running. A runtime error happens while it runs, often in front of a user.
Dynamically typed: A value's kind is only checked when the line runs. JavaScript works this way.
Statically typed: Kinds of values are checked by reading the code, before it runs. TypeScript adds this to JavaScript.
Type checker: The part of TypeScript that reads your code and reports every place a type promise is broken.
Type error: A message from the checker saying a value doesn't fit where you used it, like text passed where a number was promised.
Autocomplete: The editor suggesting names as you type, possible because it knows each value's type.

Step by step

01The bug: a price that becomes text

A shop page reads a price from a form field and adds 18% tax. Form fields always give you a string (text), even if the person typed 100.

In JavaScript, + with a string glues text together. So "100" + "100" * 0.18 becomes "100" + 18, which is the text "10018". No error, no warning: the page shows ₹10018.

price.jswhole filejs

function addTax(price) {
  return price + price * 0.18;
}

const fromInput = "100"; // what a form field gives you
console.log(addTax(fromInput)); // 10018 (wrong, and nobody is told)

02Write the promise down

In TypeScript you add : number after the parameter. That is a type annotation: it promises addTax is only ever given a number.

Now the checker compares every call with the promise. addTax(fromInput) passes a string, so it reports an error on that exact line, with a code (TS2345) and a plain message. "Not assignable" just means "does not fit" (Topic 0.2 explains the word).

price.tswhole filets

function addTax(price: number) {
  return price + price * 0.18;
}

const fromInput = "100";
console.log(addTax(fromInput));
// error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

03Fix it where the data enters

The error points you to the real problem: the value needs converting when it comes in. Number(fromInput) turns the text into the number 100.

With the fix, the checker is happy and the program prints 118. The bug never reached a user.

price.tswhole filets

const fromInput = "100";
console.log(addTax(Number(fromInput))); // 118

04Typos are bugs too

JavaScript lets you read a property that doesn't exist and quietly gives undefined. A typo like user.nmae turns into the text Hello, undefined on the page.

TypeScript knows user only has name and city, so user.nmae is an error: Property 'nmae' does not exist on type '{ name: string; city: string; }'. Notice you never wrote a type for user: TypeScript inferred it (worked it out) from the object you wrote.

05Where TypeScript sits in your work

You write .ts files. The checker runs in your editor as you type and again in your build. Then the types are removed and plain JavaScript runs in the browser or in Node.js. Topic 0.2 opens this up.

Where TypeScript sits in your workdiagram

Rendering diagram…

Try it yourself

1
Fix the price
In the first example, predict what happens if you change the last line to console.log(addTax(Number(fromInput)));.
Check: the Types panel says No type errors and the console prints 118.
2
Change a promise
In the third example, change const year = 2026; to let year = 2026;. Predict the new type before you look.
The panel now says let year: number. A const can never change, so TypeScript keeps the exact value 2026 as its type; a let could later hold any number. You'll study this in Topic 1.3.
3
Pass the wrong thing
Add a line average("90, 72"); to the third example. Read the error before you scroll: which argument, which type was expected?
Check: Argument of type 'string' is not assignable to parameter of type 'number[]'. The call passes one piece of text where a list of numbers was promised.

Code & diagrams

The price bug: TypeScript warns, JavaScript runs it anyway

The Types panel shows the error tsc reports. The code still runs (like tsc, the editor emits JavaScript anyway), so the Console shows the wrong price the error predicted. Change the last line to addTax(Number(fromInput)).

Console

(nothing was printed)

Expected console output

A typo JavaScript would hide

TypeScript worked out the object's type from the code and knows nmae isn't in it. Fix the typo and the error disappears.

Console

(nothing was printed)

Expected console output

Hello, undefined

TypeScript works out most types for you

A line with // ^? asks: what is the type of the name just above the caret? The answers appear in the Types panel. Only nums needed an annotation; everything else was inferred.

Console

(nothing was printed)

Expected console output

82.33333333333333

Break it on purpose

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

Break #1

Remove the annotation

In the first example, delete : number so the function starts function addTax(price) {.

terminal

$ Types panel

── what you'll see ──

index.ts(1,17): error TS7006: Parameter 'price' implicitly has an 'any' type.

Myth vs fact

Myth

TypeScript is a different language you have to learn from scratch.

Fact

It is JavaScript with extra syntax for types. Your JavaScript knowledge carries over completely, and plain JavaScript is almost always valid TypeScript.

Myth

If it type-checks, it has no bugs.

Fact

TypeScript catches a large class of mistakes (wrong kinds of values, typos, missing cases), but not wrong logic, wrong numbers or bad data arriving at runtime.

Myth

TypeScript makes the program run faster or slower.

Fact

Types are removed before the code runs. The JavaScript that runs is essentially what you would have written by hand, so speed is the same.

Pro corner

Extra depth for experienced readers. New to this? Skip it for now and come back later.

▸
TypeScript's type system is structural (it compares shapes, not names) and deliberately unsound in a few places to stay practical with existing JavaScript. Topic 3.5 and Topic 16.5 cover both: knowing where the holes are is what separates confident users from experts.
▸
The biggest gains come from the editor, not from the build step. The same checker powers the language server behind VS Code's autocomplete, go-to-definition and rename. TypeScript 7 rewrote this in Go, cutting VS Code's own time-to-first-error from about 17.5 s to under 1.3 s.
▸
Error codes are stable and searchable. TS2345 (bad argument), TS2322 (bad assignment), TS2339 (no such property) and TS7006 (implicit any) are the four you'll see most; learn to read the code first and the message second.

Remember this

1
The problem this solves: In plain JavaScript, a wrong kind of value, like text where a number belongs, is not noticed until the line runs. Often a user finds the bug first. JavaScript is the language every web browser runs. It is dynamically typed: a variable can hold a number now and a piece of text later, and nothing checks what you pass where until the line actually runs. That freedom is quick for small scripts, but it means many mistakes are only found at runtime (while the program is running), often by a user who sees a broken page.
2
A type is a promise about a value: what kind of thing it is and what you can do with it. number promises arithmetic works. string promises text methods like toUpperCase() exist. { name: string } promises an object with a name that is text. When the promise is written down, a tool can check every place the value is used.
3
TypeScript is JavaScript with a way to write those promises down, plus a program, the type checker, that reads your code and checks every promise. This is static checking: "static" means the code is examined without running it, the way a teacher can spot a spelling mistake without reading the essay aloud. Every JavaScript program is already almost a valid TypeScript program; TypeScript only adds things, it never changes what JavaScript code does.
4
The classic bug: text from a form field is always a string, even when the person typed digits. In JavaScript, "100" + 18 glues text together and gives "10018", not 118. The page shows a wrong price and nobody knows why. In TypeScript, passing that string to a function that promised to take a number is a red error in the editor (you'll run it in the first example below). The bug is found in seconds instead of in a customer complaint.
5
Types also make the editor smart. Because TypeScript knows that user has name and city, it can autocomplete them when you type user., warn about a typo like user.nmae, jump to where something is defined and rename it safely everywhere. Big teams use TypeScript mostly for this: in a codebase with a million lines, nobody remembers what every function takes.
6
Who uses it? TypeScript was released by Microsoft in 2012 and is free and open source. Today it is the default for new front-end and Node.js projects: VS Code, Angular, Slack, Airbnb, Stripe and most React codebases are written in it, and most npm packages ship type information. It is now one of the most used languages on GitHub. Most web teams expect you to read it.
7
TypeScript has limits worth knowing on day one. It checks your code, not the data that arrives at runtime: if a server sends { msg: 42 } when you said it would send text, TypeScript can't see that (Topic 0.2 shows this, and Topic 13.4 shows how to check data at runtime). And a checked program can still have logic bugs: TypeScript knows a price is a number, not that it is the right number.

Explain it without notes

What is TypeScript, in one minute?

What does "static type checking" mean, and how is it different from what JavaScript does?

Why do teams adopt TypeScript if it doesn't make code run faster?

What can't TypeScript catch?

Practice

Add a type annotation so this function only accepts numbers, then call it once correctly and once with a string. Write down the error tsc gives. ``ts function square(n) { return n * n; }

This code prints Total: 102030 instead of Total: 60. Add types so TypeScript finds the bug, then fix it. ``ts const prices = ["10", 20, 30]; console.log("Total: " + prices.reduce((a, b) => a + b));

Trade-offs

↔
TypeScript adds a build step and some typing effort; in return you get far fewer runtime surprises and a smarter editor. For a 20-line script the cost can outweigh the gain; for anything a team maintains, it almost never does.
↔
Types describe what you *believe*. Wrong types are worse than none, because people trust them. Keep types honest at the edges where data enters (Topic 13.4).

Done when you can

I can explain what TypeScript adds to JavaScript in one sentence.
I can explain static vs runtime checking with the "100" + 18 example.
I can read a type error line: which line, which code, what the message says.
I can use // ^? in the live editor to see a type.
I can name two things TypeScript cannot catch.

Command Palette

Words you'll meet

Step by step

01The bug: a price that becomes text

02Write the promise down

03Fix it where the data enters

04Typos are bugs too

05Where TypeScript sits in your work

Try it yourself

Fix the price

Change a promise

Pass the wrong thing

Code & diagrams

Break it on purpose

Remove the annotation

Myth vs fact

Pro corner

Remember this

Explain it without notes

Practice

Trade-offs

Done when you can