The bugs TypeScript exists to prevent

Before you learn how TypeScript works, it is worth feeling the problem it solves — sharply enough that the effort of learning it feels obviously worth it. That problem is JavaScript's, and it is this: JavaScript will let you write almost any nonsense, and only tell you it was nonsense when a user hits it, in production.

The language that says yes to everything

JavaScript is permissive by design. It will happily let you do all of these, with no complaint, right up until the code runs:

function total(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

total("hello");           // items.reduce is not a function — but only at runtime
total([{ cost: 100 }]);   // sum + undefined = NaN — silently wrong
total();                  // Cannot read properties of undefined — crash

Every one of those is a bug, and JavaScript ships all three without a word of warning. The first crashes because a string has no reduce. The second returns NaN because the property is cost, not price — no crash, just a wrong number that flows through your app. The third crashes because nobody passed anything. You find out about each one when it happens to a user, which is the worst possible time and place.

The bugs it prevents, concretely

TypeScript exists to catch this whole family of mistakes before the code runs — while you type, in your editor. Here are the ones it eliminates, which together are a startling fraction of real production bugs:

Wrong types passed to functions. total("hello") — TypeScript knows total wants an array and refuses the string. The bug never compiles, let alone ships.

Misspelled or wrong property names. item.cost when the property is price — TypeScript knows the shape of item and tells you cost does not exist on it, suggesting price. The silent-NaN bug is gone.

Missing arguments. total() with no array — TypeScript knows the parameter is required and flags the call.

null and undefined where a value was expected. The single most common JavaScript crash — Cannot read properties of undefined — becomes a compile error, because TypeScript tracks which values might be absent (a whole theme of this course).

Using a value the wrong way. Calling something that is not a function, indexing something that is not an array, .toUpperCase() on a number. All caught before the program runs.

The same code, typed

Here is total with types, and watch what the compiler now knows:

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

function total(items: Item[]): number {
  return items.reduce((sum, item) => sum + item.price, 0);
}

total("hello");              // error: Argument of type 'string' is not assignable to parameter of type 'Item[]'
total([{ cost: 100 }]);      // error: Object literal may only specify known properties; 'cost' does not exist
total();                     // error: Expected 1 arguments, but got 0
total([{ name: "Chai", price: 1500 }]);   // fine — returns 1500

Four lines that used to be runtime disasters are now compile errors, each pointing at the exact problem, before you have run anything or bothered a user. That is the entire value proposition: move the discovery of a huge class of bugs from production, where they are expensive and embarrassing, to your editor, where they cost seconds.

Why this matters more the bigger things get

On a ten-line script, you can hold the whole thing in your head, and these bugs are rare. TypeScript earns its keep as programs and teams grow:

• On a large codebase, you cannot remember the shape of every object and the signature of every function. The types remember for you, and the compiler checks you used them correctly.
• On a team, you call code your colleagues wrote and did not explain. The types are the explanation — the compiler enforces the contract so you cannot use their function wrongly.
• When you change code, TypeScript shows you every place your change breaks. Rename a property, and every use that now refers to nothing lights up red — so you can refactor with confidence instead of fear. This "change without fear" is one of the biggest day-to-day wins.

It is not an accident that essentially every serious JavaScript project — React apps, Node backends, Angular, NestJS — is now written in TypeScript. The larger and more important the code, the less tolerable JavaScript's "find out in production" model becomes.

What it costs, honestly

TypeScript is not free, and pretending otherwise sets you up to resent it:

• You write more. Type annotations are extra characters, and sometimes the types get genuinely fiddly.
• You will fight the compiler, especially early, when it rejects code you are sure is fine. Often it is right and you were wrong; sometimes the type is just hard to express. Learning which is which is part of this course.
• There is a build step. TypeScript does not run directly; it compiles to JavaScript first (the next lessons explain this). That is one more moving part.

The trade is deliberate: a little more effort while you write, in exchange for a lot less debugging after you ship. For anything beyond a throwaway script, that trade is overwhelmingly worth it — which is why this course exists, and why the Full-Stack course that follows is written entirely in TypeScript.

Check your work

JavaScript's core problem. It permits almost any nonsense and only reports it at runtime, in production, in front of a user.

Three bugs in the untyped total. A wrong type ("hello"), a misspelled property (cost for price, giving a silent NaN), and a missing argument.

The families of bug TypeScript catches. Wrong types to functions, wrong/misspelled property names, missing arguments, null/undefined misuse, and using a value the wrong way.

When TypeScript catches them. At compile time, in your editor, before the code runs.

Why it matters more as things grow. You cannot remember every shape and signature; the types do, and they enforce contracts across a team and make change safe.

Why nearly all serious JS is now TypeScript. The bigger and more important the code, the less tolerable "find out in production" is.

What TypeScript costs. More to write, fighting the compiler early, and a build step — traded for far less production debugging.

Practice

1. In plain JavaScript, write total and call it with a string, a wrong property name, and no argument. Run each and observe how (and when) each fails.
2. For each of those three failures, note where you found out about it — you had to run the code.
3. List three bugs you (or an app you use) have hit that were "a value was the wrong type or shape". Consider whether a type checker would have caught each.
4. Explain, in two sentences, why TypeScript helps more on a large team codebase than on a personal ten-line script.
5. Write down one honest cost of TypeScript and one benefit, and decide for a project you know whether the trade is worth it.

Official documentation

• TypeScript — The Basics — The problem and the type checker, from the source.
• TypeScript for the New Programmer — Why static types, gently.
• TypeScript Playground — Try the typed and untyped total in the browser, no install.

Next: how the type checker actually works, and what it cannot do.