TypeScript

In short: A superset of JavaScript developed by Microsoft, adding static typing.

In more detail: Compiled (“transpiled”) to normal JavaScript, so it runs anywhere JS runs. The compiler checks whether types match before execution (e.g. whether a function is called with the correct parameter types), catching many bugs already during development instead of only at runtime.

In Depth

Origin

TypeScript was released by Microsoft in 2012, led by Anders Hejlsberg (who had previously also co-developed C# and Delphi). The trigger: JavaScript was originally designed in just ten days in 1995 for small scripting tasks in the browser, with no type system — as large, complex JavaScript applications emerged (single-page apps, large codebases with many developers), the limits of this design became apparent: typos in object properties, incorrectly passed function parameters, or undefined access often only showed up at runtime, sometimes only for the customer. TypeScript was meant to catch this class of bugs through static type checking already during development, without replacing the JavaScript language itself.

A genuine superset

function greet(name: string, age: number): string {
  return `Hello ${name}, you are ${age} years old.`;
}
 
greet("Anna", "thirty"); // compiler error: argument of type "string" is not
                          // assignable to parameter of type "number"

“Superset” specifically means: every valid JavaScript file is automatically also valid TypeScript (the file extension changes, the code doesn’t) — you can migrate existing JS code gradually, file by file, to TypeScript, instead of having to rewrite everything at once. The second call in the example would silently produce a wrong result in plain JavaScript (e.g. NaN in a subsequent calculation) and only make the bug visible at runtime, often at a completely different point in the program than the actual cause. TypeScript, by contrast, reports the type conflict already at compile time — and practically always already live in the editor via a red underline, long before the code is even executed.

Structural instead of nominal typing

interface Point { x: number; y: number; }
 
function distanceFromOrigin(p: Point): number {
  return Math.sqrt(p.x ** 2 + p.y ** 2);
}
 
// Works, even though "object" was never explicitly declared as "Point" -
// the SHAPE fits, that's enough.
const object = { x: 3, y: 4, color: "red" };
distanceFromOrigin(object);

TypeScript’s type system is “structural”: two values count as compatible if they have the same shape (the same fields with matching types) — regardless of whether they were explicitly declared as the same type, and even if (as in the example) extra fields are present. This distinguishes TypeScript from “nominally” typed languages like Java or C#, where two objects are only compatible if they’re linked via the same declared class name, even with an identical field structure. Structural typing is closer to JavaScript’s originally dynamic, “duck-typed” nature (“if it quacks like a duck…”) and makes integration with existing, untyped JS code easier.

Compiling, not interpreting

TypeScript code never runs directly anywhere — the TypeScript compiler (tsc) first translates it into plain JavaScript (type annotations are completely removed in the process, they only exist at compile time), which is then executed perfectly normally in the browser or in Node.js. This also means: TypeScript’s type checking offers no protection at RUNTIME whatsoever — data coming from, say, an external API via fetch() can have a completely different shape at runtime than the stated type, if the API changes; TypeScript blindly trusts the type annotations.

Types for third-party code

For existing JavaScript libraries that don’t use TypeScript themselves, types can be provided afterwards via separate declaration files (.d.ts), without touching their actual code — either shipped by the library itself, or via the community project DefinitelyTyped (@types/package-name). This lets TypeScript work well with the huge existing JavaScript ecosystem, including libraries like React, without it having to be completely rewritten.

See also: JS, Java, React