TypeScript Introduction

Why types on top of JavaScript?#

TypeScript, created by Microsoft and first released in 2012, is a superset of JavaScript that adds a static type system. Every valid JavaScript file is already valid TypeScript — you adopt it incrementally, and it compiles down to plain JavaScript that runs anywhere JavaScript already runs (browsers, Node.js).

The core problem it solves: JavaScript only tells you about a type mismatch when the buggy line actually executes, sometimes in production. TypeScript catches an entire class of these mistakes before the code ever runs, directly in your editor:

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

greet("Ada");    // fine
greet(42);       // Compile-time error: Argument of type 'number' is not assignable to parameter of type 'string'

Beyond catching bugs early, types make code self-documenting — a function's signature tells you exactly what it expects and returns without needing to read its implementation — and they unlock much richer editor tooling: accurate autocomplete, reliable "find all references," and safe automated refactors across an entire large codebase.

Installing TypeScript#

TypeScript is a dev dependency in almost every project — installed locally per-project rather than globally, so everyone on a team compiles with the exact same version:

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

Verify it and scaffold a config file:

npx tsc --version
# Version 5.5.4

npx tsc --init
# Creates tsconfig.json

tsconfig.json basics#

tsconfig.json tells the compiler how to interpret and compile your project. A sensible minimal starting point:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "outDir": "dist",
    "rootDir": "src",
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}

strict: true is the single most important setting — it's what makes TypeScript actually catch bugs, rather than just quietly accepting any everywhere.

Compiling with tsc#

Write a file src/hello.ts:

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

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

Compile the whole project according to tsconfig.json:

npx tsc
# Emits dist/hello.js

Run the compiled JavaScript output with Node:

node dist/hello.js
# Hello, World!

For faster iteration during development, tsc --watch recompiles automatically on save, and tools like ts-node or tsx can run .ts files directly without a separate compile step — handy for quick scripts, though production builds still go through a real tsc (or bundler) compile.

Common mistakes#

• Forgetting to enable strict mode — without it, TypeScript silently allows any in many more places and catches far fewer real bugs.
• Treating .ts files as if they run directly — they must be compiled (or run through a tool like ts-node/tsx) to plain JavaScript first; Node and browsers cannot execute .ts natively.
• Committing the dist/outDir compiled output to version control — it's a build artifact and normally belongs in .gitignore.

Interview questions#

Q: Does TypeScript run directly in the browser or Node.js? No — TypeScript is compiled ("transpiled") to plain JavaScript first, either via tsc directly or as part of a bundler's build step (webpack, esbuild, Vite). Neither browsers nor Node.js execute .ts files natively.

Q: What's the practical benefit of TypeScript over plain JavaScript? It catches an entire category of bugs — wrong argument types, typos in property names, calling a method that doesn't exist on a type — at compile time, in your editor, instead of at runtime in production. It also makes large codebases far more navigable, since accurate types power reliable autocomplete, "go to definition," and safe rename-across-files refactors.