Why TypeScript?

A bug caught before anyone sees it

A shop page adds up a cart. Tea costs 3 and cake costs 4, so the total should be 7. But the cake's price came from a form, and a form gives you text, not a number. Here is what plain JavaScript does with that:

const teaPrice = 3;
const cakePrice = "4"; // typed into a form, so it's text
console.log(teaPrice + cakePrice);

Line 1 stores the number 3. Line 2 stores "4" in quotes, which is text. Line 3 adds them and prints 34. When one side of + is text, JavaScript joins the two instead of adding them (the Type conversion lesson explains why). Nothing warns you. The first person to notice might be a shopper looking at a total of $34.

TypeScript lets you say what kind of value each name should hold. That kind is called a type. Here is the same code with two types added:

1const teaPrice: number = 3;2const cakePrice: number = "4";3console.log(teaPrice + cakePrice);

Line 1 says teaPrice is a number, and it is. Line 2 says cakePrice is a number too, but gives it text. TypeScript marks line 2 with an error, on purpose here, because it's the bug:

• Type 'string' is not assignable to type 'number' means "you're putting text where a number has to go". A string is text, and "assignable" means "allowed to be stored there".
• ts(2322) is the error's number. Every TypeScript error has one, so you can look it up.

The list under the code comes from the real TypeScript compiler, running in this page. Point at a name to see its type. Now try it yourself: type a different value for the cake's price, and watch the list under the code as you type.

1const teaPrice: number = 3;2const cakePrice: number = "4";3console.log(teaPrice + cakePrice);

With 4 or Number("4"), line 2 holds a number, so the error disappears. Put the quotes back and it returns. true and four get errors of their own, and an empty box gets Expression expected, because line 2 needs a value. Every TypeScript example in this lesson works the same way: press Edit & run, change the code, and the errors update as you type.

JavaScript with types

TypeScript isn't a new language you have to learn from the start. Almost any JavaScript is already TypeScript. Here is plain JavaScript, with no types written at all, checked by TypeScript:

1const user = { name: "Asha", cartItems: 2 };2const greeting = `${user.name} has ${user.cartItems} items`;3//    ^?4console.log(greeting);

Line 1 makes a user object with a name and a number of cart items. Line 2 builds a message from them with a template literal. Line 4 prints Asha has 2 items. There are no errors.

Line 3 is a comment, so it changes nothing when the code runs. In this lesson a comment like // ^? asks a question: "what type is the name my ^ points at?" The page writes TypeScript's answer after it: const greeting: string. You never wrote string. TypeScript worked it out from the value, which is called inference. In your own editor, you get the same answer by pointing at the name.

When you want to say a type yourself, you write a colon and the type after a name. This is called a type annotation. Functions are where you'll write them most:

1function lineTotal(price: number, quantity: number) {2  return price * quantity;3}4 5const total = lineTotal(3, 2);6//    ^?7console.log(total);

Line 1 says lineTotal takes a price that is a number and a quantity that is a number. Line 2 multiplies them. Line 5 calls it with 3 and 2. The query on line 6 shows that TypeScript knows total is a number, without an annotation on line 5. Line 7 prints 6.

Browsers can't run price: number; it isn't JavaScript. So TypeScript does two jobs. First it checks the types. Then it removes them, and what's left is plain JavaScript. The program that does this is the TypeScript compiler, called tsc. Here is what it gives the browser for the example above:

function lineTotal(price, quantity) {
  return price * quantity;
}

const total = lineTotal(3, 2);
console.log(total);

Line 1 has lost its two : number annotations. The rest is the same code, and it still prints 6. The query comment is left out here: it only asked TypeScript a question, and a comment does nothing when the code runs. The next lesson, How TypeScript works, follows this step closely.

The table below compares the two. Read each row as a question, then each language's answer.

Bugs caught while you type

The price bug from the start of the lesson is one of many mistakes TypeScript points at before your code runs. Try it on a whole cart. The code has a type alias on line 1: type CartItem = … gives a name to the shape every cart item must have, a name that is text and a price that is a number. Line 3 says cart is a list of those items.

1type CartItem = { name: string; price: number };2 3const cart: CartItem[] = [4  { name: "Tea", price: 3 },5  { name: "Cake", price: 4 },6];7 8let total = 0;9for (const item of cart) {10  total += item.price;11}12console.log(`Total: $${total}`);

Press each button and watch the list under the code. With A number, there are no errors and the total is $7. Text from a form puts "4" on line 5: the error appears, and the shopper would see $34. Text, converted wraps it in Number(…), which turns text into a number, and the error disappears. Price left out gets Property 'price' is missing, because every CartItem needs a price; the shopper would see NaN, which means "not a number". You can also press Edit & run and type any price you like on line 5.

Here are three more mistakes. Each one gets its error on purpose. First, a misspelled property:

1const cart = { items: 2, total: 7 };2console.log(cart.totl);

Line 1 makes a cart with items and total. Line 2 asks for cart.totl. TypeScript knows the cart has no totl, and its message even suggests the fix: Did you mean 'total'? Plain JavaScript would print undefined.

1function applyDiscount(total: number, percent: number) {2  return total - (total * percent) / 100;3}4console.log(applyDiscount(20));

Line 1 says applyDiscount takes a total and a percent. Line 2 takes the percent off the total. Line 4 calls it with only 20. TypeScript says Expected 2 arguments, but got 1. Plain JavaScript would use undefined for the missing percent and print NaN.

1const cart = [{ name: "Tea", price: 3 }];2const cake = cart.find((item) => item.name === "Cake");3console.log(cake.price);

Line 1 makes a cart with only tea. Line 2 uses find, which gives back the first item that matches, or undefined when none does (Searching arrays covers it). There's no cake, so cake is undefined. Line 3 reads its price. When this runs, JavaScript throws a TypeError and the code stops. TypeScript saw it coming: 'cake' is possibly 'undefined'.

The table below puts the four mistakes side by side. Read each row as: this mistake, then what each language does about it.

Editor help: autocomplete and rename

Because TypeScript knows the type of every value, your editor can use that knowledge while you write. Editors like VS Code ask TypeScript about your code all the time, even in plain .js files. Here is what TypeScript knows about one object:

1const settings = { theme: "dark", fontSize: 16, showTips: true };2//    ^?3settings.fontSize = 18;

Line 1 makes a settings object for a page: a theme, a font size, and whether to show tips. The query on line 2 shows the type TypeScript worked out: theme is a string, fontSize is a number, and showTips is a boolean (true or false). Line 3 changes the font size to 18, which is fine because 18 is a number.

That type is how autocomplete works. When you type settings., the editor lists the three properties, so you pick a name instead of remembering how to spell it:

The same knowledge makes renaming safe. Say you decide price should be called unitPrice. In plain JavaScript, you search for every price and hope you found them all. With TypeScript, change the name in the type, and every place still using the old name gets an error. Step through a rename:

1type CartItem = { name: string; price: number };2 3const tea: CartItem = { name: "Tea", price: 3 };4const cake: CartItem = { name: "Cake", price: 4 };5 6function lineTotal(item: CartItem, quantity: number) {7  return item.price * quantity;8}9 10console.log(lineTotal(tea, 2) + lineTotal(cake, 1));

Step 2 changes only line 1, and TypeScript lists lines 3, 4, and 7: a to-do list of places to update. Step 3 updates the two objects, and only line 7 is left. That is the dangerous moment in plain JavaScript: the objects say unitPrice, line 7 reads price, and the order quietly costs NaN. Step 4 fixes line 7, and the errors are gone. In VS Code, the Rename Symbol command (the F2 key) does all of this in one go, because it uses the same types.

What TypeScript doesn't do

TypeScript checks your code before it runs. Once it has removed the types, its job is done. So it can't check anything that only exists while the page runs, like a reply from a server:

1type Product = { name: string; price: number };2 3const reply = '{ "name": "Cake", "price": "4" }';4const cake: Product = JSON.parse(reply);5//    ^?6console.log(cake.price + 3);

Line 1 describes a Product: a name and a number price. Line 3 is the reply as the server sent it, and its price is the text "4". Line 4 turns the reply into an object with JSON.parse and says it's a Product. The query on line 5 shows TypeScript believes you: const cake: Product. There are no errors, but line 6 prints 43, because the price is really text.

JSON.parse can give back anything, so TypeScript can't know what's inside. It trusts the type you wrote. (The JSON lesson covers JSON.parse itself.)

TypeScript also can't tell that a calculation is wrong when every type is right:

1function lineTotal(price: number, quantity: number) {2  return price + quantity;3}4console.log(lineTotal(3, 2));

Line 2 should multiply the price by the quantity, but it adds. Both are numbers, so every type is right, and line 4 prints 5 instead of 6 with no error. Tests, and trying your page, find this kind of mistake.

The table below lists jobs you might expect from TypeScript. Read each row as: this job, does TypeScript do it, and why.

TypeScript also has costs. They're worth knowing before you start:

• A build step: something has to remove the types before the browser runs your code.
• New things to learn: the type syntax, and how to read the error messages.
• Time spent writing types, mostly for data that comes from outside, like server replies.
• Now and then, code you know is right needs a small change before TypeScript accepts it.

For most frontend projects, the bugs it catches early are worth that cost, which is why so many teams use it.

A quantity box on a checkout page

On a real checkout page, the shopper types how many cakes they want into a box. The page reads the box with .value, and adds one when they press a plus button. TypeScript already knows the browser's own types, like what an <input> element holds:

1const quantityInput = document.createElement("input");2quantityInput.value = "2";3 4const quantity = quantityInput.value;5//    ^?6const nextQuantity: number = quantity + 1;7console.log(nextQuantity);

Line 1 makes an <input> text box, and line 2 puts "2" in it, as if the shopper typed 2 (Form elements covers inputs and .value). Line 4 reads the value. The query on line 5 shows it's a string: a text box always gives text. Line 6 adds 1 and says the result must be a number. TypeScript marks line 6, because text plus 1 is text. Run it anyway and it prints 21.

1const quantityInput = document.createElement("input");2quantityInput.value = "2";3 4const quantity = Number(quantityInput.value);5//    ^?6const nextQuantity: number = quantity + 1;7console.log(nextQuantity);

The only change is line 4: Number(quantityInput.value) turns the text into a number as it comes in. The query on line 5 now says number, the error is gone, and line 7 prints 3. Converting outside data once, at the point it arrives, is the habit TypeScript pushes you toward.

Common mix-ups

TypeScript only catches a wrong type when it knows the right one. Here is the price bug again, with no types written:

1const teaPrice = 3;2const cakePrice = "4";3console.log(teaPrice + cakePrice);

Line 1 makes teaPrice a number, and line 2 makes cakePrice a string. Line 3 joins them and prints 34, and TypeScript reports nothing. Joining text with + is allowed, and often exactly what you want. The overview caught the bug only because line 2 said cakePrice must be a number.

• "TypeScript is a different language from JavaScript." No. It's JavaScript with types added. The browser runs the JavaScript that's left when the types are removed.
• "TypeScript checks my data while the page runs." No. The types are gone by then. A server reply with a price as text gets through, as the 43 example showed.
• "No errors means no bugs." No. A sum with + where you meant * has the right types and the wrong answer.
• "I have to write a type on every variable." No. TypeScript works out most types from the values, like const total: number. You write types mostly for function parameters and outside data.
• "A type error stops my code from running." No. The overview's typed example still prints 34 when you run it. The error is a warning for you. The next lesson shows what the compiler does with code that has errors.
• "TypeScript makes my code faster." No. The browser runs the same JavaScript either way.

Practice exercises

Each exercise is TypeScript. When you fix code, press Edit & run on the starter code: the errors update as you type, and the console shows what it prints. Try a guess first, then use the hints.

type CartItem = { name: string; price: number };

const tea: CartItem = { name: "Tea", price: 3 };
const cake: CartItem = { name: "Cake", price: "4" };

1type CartItem = { name: string; price: number };2 3const tea: CartItem = { name: "Tea", price: 3 };4const cake: CartItem = { name: "Cake", price: "4" }; // line 4 has the error

1const order = { id: 7, paid: false };2const paid = order.paid;

1const order = { id: 7, paid: false };2const paid = order.paid;3//    ^?

1type CartItem = { name: string; price: number };2 3const cart: CartItem[] = [4  { name: "Tea", price: 3 },5  { name: "Cake", price: "4" },6];7 8console.log(cart[0].price + cart[1].price);

1type CartItem = { name: string; price: number };2 3const cart: CartItem[] = [4  { name: "Tea", price: 3 },5  { name: "Cake", price: Number("4") },6];7 8console.log(cart[0].price + cart[1].price);

1const settings = { theme: "dark", fontSize: 16 };2 3console.log(settings.fontsize);

1const settings = { theme: "dark", fontSize: 16 };2 3console.log(settings.fontSize);

1type Product = { name: string; price: number };2 3const reply = '{ "name": "Tea", "price": "3" }';4const tea: Product = JSON.parse(reply);5console.log(tea.price * 2 + tea.price);

1type Product = { name: string; price: number };2 3const reply = '{ "name": "Tea", "price": "3" }';4const data = JSON.parse(reply);5const tea: Product = { name: String(data.name), price: Number(data.price) };6console.log(tea.price * 2 + tea.price);

1const cart = [{ name: "Tea", price: 3 }];2const cake = cart.find((item) => item.name === "Cake");3console.log(cake.price);

1const cart = [{ name: "Tea", price: 3 }];2const cake = cart.find((item) => item.name === "Cake");3if (cake) {4  console.log(cake.price);5} else {6  console.log("No cake in the cart");7}

Check your understanding

For each question, keep two moments apart: what TypeScript says before the code runs, and what the code does when it runs. The quiz shows its code without the checker, so the error list doesn't give the answers away.

Key takeaways

• TypeScript is JavaScript plus types. A type says what kind of value a name must hold, like price: number.
• It points at wrong types while you type: text where a number goes, a misspelled property, a missing argument, a value that may be undefined.
• You don't write every type. TypeScript works most of them out, and you can see them by pointing at a name.
• Your editor uses the types for autocomplete and for renaming safely.
• The types are removed before the browser runs the code, so data that arrives while the page runs isn't checked.
• It can't find a wrong calculation with the right types, and it doesn't make code faster.

Coming next: How TypeScript works. It follows your code through the compiler: checking, removing the types, and why code with errors still runs.