What Is TypeScript?

TypeScript is a strongly-typed superset of JavaScript that compiles down to plain JavaScript. You write the same language you already know, add type annotations, and the TypeScript compiler (tsc) checks those types at build time — catching whole categories of bugs before the code ever runs.

Because the output is ordinary JavaScript, TypeScript runs anywhere JavaScript runs: browsers, Node, Deno, Bun, edge functions, React Native. The types exist only at build time and are erased from the shipped code.

How TypeScript works

TypeScript sits between your source and the JavaScript that actually executes:

1. You write .ts / .tsx files with type annotations (name: string, user: User, items: Product[]).
2. tsc (or a bundler like esbuild, swc, Vite) type-checks and strips the types, emitting plain .js.
3. The browser or runtime executes the JavaScript — it never sees the types.

A key consequence: TypeScript performs no runtime validation. Types vanish after compilation, so data crossing a trust boundary (API responses, form input, env vars) still needs runtime checks — commonly with a library like Zod. TypeScript guarantees your code is internally consistent, not that the outside world sent what you expected.

Much of TypeScript's power is inference: you rarely annotate everything. The compiler infers types from how values are used, so you mostly annotate function boundaries and let it figure out the rest.

A concrete example

// JavaScript — no error until a user triggers it in production
function greet(name) {
  return name.toUpperCase();
}
greet(42); // TypeError at runtime: name.toUpperCase is not a function

// TypeScript — the same mistake is a build error
function greet(name: string) {
  return name.toUpperCase();
}
greet(42); // Error: Argument of type 'number' is not assignable to parameter of type 'string'

The TypeScript version never compiles, so the bug never ships.

Why teams adopt it

• Bugs caught at compile time, not in production. Typos, wrong argument types, and undefined access are flagged as you type.
• Real editor support. Autocomplete, inline docs, and go-to-definition work because the editor knows the shape of every value.
• Safer refactors. Rename a field or change a function signature and the compiler lists every call site that breaks.
• Contracts live in code. API response shapes and component props are enforced by the type checker instead of relying on out-of-date docs.

When to use it — and when not

The payoff scales with how long the code lives and how many people read it. For a real product, TypeScript usually pays for itself before launch.

Common mistakes

• Reaching for any. It silences the checker and throws away every benefit. Prefer unknown and narrow the type, or model the real shape.
• Assuming types validate runtime data. They don't — validate external input (API, forms, env) at the boundary with something like Zod.
• Leaving strict off. The strict flag in tsconfig.json is where most of the safety lives, especially strictNullChecks. Turn it on from day one.
• Over-annotating. Trust inference; annotate boundaries, not every local variable.

How I use TypeScript in real projects

Every project I build is TypeScript from the first commit. In a multi-tenant SaaS, typed database schemas, typed API responses, and typed component props remove an entire class of bugs before they reach production — for example the React + Firebase clinic app Callidus and the React + Supabase ordering app Pizzeria Bestek both lean on end-to-end types so a change to a data model surfaces every affected screen at build time.

Key takeaways

• What it is: JavaScript plus a static type system that compiles away to plain JavaScript.
• What it buys you: compile-time bug catching, better tooling, and safer refactors.
• Its limit: types are erased at build time, so runtime validation of external data is still your job.
• When to skip it: genuine throwaway scripts. For anything that ships or grows, start typed.