Start TypeScript With the Code You Already Have

TypeScript is easiest to understand as JavaScript with a checker. The types help you find mistakes before the code runs, but the browser still receives JavaScript in the end.

You do not need to model an entire application on day one. Start at the boundaries where uncertainty hurts: function arguments, returned values, configuration, and data from APIs.

A five-minute setup

Create a project and install TypeScript as a development dependency:

npm init -y
npm install --save-dev typescript
npx tsc --init

Add a file named index.ts:

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

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

Run npx tsc to check and compile it. The generated tsconfig.json contains many options; turn on strict checking and change only what the project actually needs.

Types describe the values you expect

JavaScript programmers will recognise the runtime values. TypeScript adds ways to describe them:

type User = {
  id: number;
  name: string;
  role?: "admin" | "member";
};

function label(user: User): string {
  return `${user.name} (${user.role ?? "member"})`;
}

The union prevents an arbitrary role string, while ? says the property may be absent. Type inference means you do not need to annotate every local variable. If TypeScript already knows, let it know quietly.

Narrow uncertainty before using it

A union represents more than one possible type. Narrowing proves which value you have:

function format(value: string | number): string {
  if (typeof value === "number") {
    return value.toFixed(2);
  }

  return value.trim();
}

This is more useful than forcing the compiler to trust an assertion. as User does not validate anything at runtime; it only tells TypeScript to stop objecting.

API data is still untrusted

It is tempting to write this:

const response = await fetch("/api/user/1");
const user = (await response.json()) as User;

The server can still return a missing name or a string id. For important boundaries, parse and validate the data before treating it as User. TypeScript checks your program, not the honesty of a network response.

Where to go next

The TypeScript Handbook’s sections on everyday types, narrowing, functions, object types, generics, and mapped types form a good route through the language. I would learn them as a project demands them rather than reading every utility type before writing a component.

TypeScript earns its keep when it makes a change safer or an API clearer. Add it gradually, keep the types close to the real domain, and be suspicious of any solution that ends with as any and a comment promising to fix it later.