What Is TypeScript and Why Does It Exist? The Type Layer on Top of JavaScript

Version note: The code in this post targets TypeScript 7.0 and Node 26.

Predict First

Let's start with a piece of code you'll recognize from the JavaScript series. If you ran this as plain JavaScript, what would you see in the console?

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

const total = getTotal("100", 2);
console.log(total);

Make a guess: do you get an error, or do you see a number? And a second question: if this code ran in a live system for a year, do you think it would cause trouble? We'll answer in a moment, while reading the same code through TypeScript's eyes.

The Mistakes JavaScript Lets Slide

In the JavaScript series we talked about coercion: when JavaScript is asked to multiply a string by a number, it doesn't object; it converts the string to a number and carries on. The code above prints 200. It gave the right result today, but by accident. Tomorrow someone sends the price as "100 USD", the result becomes NaN, and you only notice when a user sees a strange total in their cart.

JavaScript's bugs fall into two groups. Some blow up the moment the code runs, like calling a function that doesn't exist. The second, sneakier group never blows up; it quietly keeps going with a wrong value. Misspelling a property name (user.nmae), calling a string method on a number, or passing a function an argument of a different type than it expects all belong to this group. To catch them you have to run the code, trigger the right scenario, and get lucky.

What Is TypeScript? The One-Sentence Answer

TypeScript is a language that adds a type system on top of JavaScript and checks your code against those types before it runs. It is developed by Microsoft and is open source.

The most important idea is this: TypeScript is a superset. Every valid piece of JavaScript is also valid TypeScript. You are not learning a new language; you are adding a layer to the one you already know, a layer that says what kinds of values your variables and functions carry. Here is the function above written in TypeScript:

function getTotal(price: number, quantity: number) {
  return price * quantity;
}

// Error: Argument of type 'string' is not assignable to parameter of type 'number'.
const total = getTotal("100", 2);
console.log(total);

The : number next to the parameters is a type annotation. We're saying "this function expects two numbers." Now the getTotal("100", 2) line is underlined in red the moment you type it in your editor, before the code ever runs. The TypeScript compiler reports the error like this:

error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

That's also the answer to the opening question: in plain JavaScript the code runs and prints 200, but it's buggy code that runs. TypeScript rejects the same code without ever running it.

Two Separate Moments: Compile Time and Runtime

The key to understanding TypeScript is to separate two moments. At compile time, the TypeScript compiler reads your code, checks the types and reports errors. At runtime, what runs your code is still a JavaScript engine: the browser or Node.js. Browsers don't know TypeScript; TypeScript code is turned into plain JavaScript before it runs.

In that transformation, all types are erased. Consider this code:

function greet(name: string): string {
  return `Hello, ${name}!`;
}

console.log(greet("Ada")); // Hello, Ada!

When the compiler turns it into JavaScript, the result is the same code with the annotations removed:

function greet(name) {
  return `Hello, ${name}!`;
}

console.log(greet("Ada"));

Think of it like scaffolding on a construction site. Scaffolding lets the workers work safely while the building goes up; when the building is finished, it comes down and leaves no trace. Types protect you during development, then they're taken down. This has an important consequence: TypeScript checks nothing at runtime. If unexpected data arrives from an API, the types won't protect you unless you validate it by hand. We'll come back to this in upcoming posts, together with the unknown type and type guards.

What Does Type Checking Catch?

Let's see what TypeScript gives you from day one with an example:

const user = { name: "Ada", age: 36 };

// Error: Property 'nmae' does not exist on type '{ name: string; age: number; }'.
console.log(user.nmae);

// Error: Property 'toUpperCase' does not exist on type 'number'.
user.age.toUpperCase();

Notice that we didn't write a single annotation here. TypeScript worked out by itself that the user object holds a string called name and a number called age. This is called type inference, and in most of the TypeScript you write you won't need to write types at all. When to write a type and when to trust inference gets a post of its own.

The errors it catches go beyond typos. Your editor changes too: the moment you type user. it lists the properties that exist, it shows which parameters a function expects, and when you rename a property it updates every place that uses it. In a large codebase, that's the difference between walking a city with a map and without one.

What TypeScript Is Not

Let's clear up a few wrong expectations up front. TypeScript doesn't make your code run faster; what runs is still the same JavaScript. It doesn't catch every bug either; it can't find logic errors, a miscalculated discount or a wrong if condition for you. And TypeScript isn't a framework; it's a language you can use in any JavaScript project, in the browser or on the server.

It also has a cost: writing types and dealing with the compiler's complaints can feel slow at first. For a small, one-off script, that cost can outweigh the gain. But in any project that several people touch and that will live for months, the type system pays for itself very quickly.

A Short History and Today's TypeScript

TypeScript was released in 2012, and for its first decade its compiler was written in TypeScript. With TypeScript 7.0, released in July 2026, the compiler was rewritten from scratch in Go, making type checking many times faster on large projects. The code you write as a language didn't change, but the new defaults that arrived earlier with 6.0 still apply in 7.0: in a new project, strict mode is now on by default. All the examples in this series are written with these current defaults. We'll talk about what TypeScript 7 brings separately at the end of the series.

How These Series Will Unfold

We teach TypeScript in three series. In the Basics series we'll set up the environment and cover type inference and annotations, basic types, array and object types, unions and narrowing, functions, tsconfig and TypeScript in the browser. In the Intermediate series we move on to generics, classes, utility types, type guards, modules and declaration files. In the Advanced series we go down to type-level programming with conditional and mapped types, decorators and the details of TypeScript 7.

We assume you've read the JavaScript series; we won't re-teach the language itself. You'll be able to run every example either in the TypeScript Playground or on your own computer.

A Small Experiment

★☆☆ Open typescriptlang.org/play in your browser. Paste the getTotal example from this post and hover over the red underline below the faulty line. Read the message, then replace "100" with 100 and watch the error disappear.

★★☆ In the Playground, switch to the ".JS" tab on the right and look at the JavaScript output of the greet function. Confirm with your own eyes where the annotations went.

★★☆ Predict whether it compiles, then try: const count = 5; count.toFixed(2); and const label = "5"; label.toFixed(2);. Why does TypeScript object to the second line even though you didn't write a single annotation?

The Playground is great for experiments, but real projects live on your own computer. In the next post we'll install TypeScript and learn both to run code and to put it through type checking, and we'll talk about why those two aren't the same thing.