Why TypeScript and Structural Typing

The Real Reason TypeScript Exists

JavaScript at scale is a game of telephone. A function written six months ago by someone who left the company accepts an object — but which fields? What types? What's optional? You check the implementation, trace the callers, read the tests, grep for usage. Twenty minutes later you have a guess.

TypeScript eliminates that guessing. But it doesn't do it the way Java or C# does. TypeScript uses structural typing — a fundamentally different approach that matches how JavaScript actually works, not how class-based languages wish it worked.

Structural vs Nominal Typing

In nominal type systems (Java, C#, Swift), types are defined by their name and explicit declaration. Two types with identical fields are still different types if they have different names:

// Java — nominal typing
class Point { int x; int y; }
class Coordinate { int x; int y; }

Point p = new Coordinate(1, 2); // ERROR: Coordinate is not Point
// Same fields, different names — incompatible

In structural type systems (TypeScript, Go interfaces), types are defined by their shape. If two types have the same structure, they're compatible:

// TypeScript — structural typing
type Point = { x: number; y: number };
type Coordinate = { x: number; y: number };

const p: Point = { x: 1, y: 2 };
const c: Coordinate = p; // OK — same shape

TypeScript doesn't care that Point and Coordinate are different names. It cares that both have x: number and y: number. Shape matches — assignment works.

Why TypeScript Chose Structural Typing

JavaScript is a dynamically-typed language where objects are just bags of properties. There are no class registries, no type declarations at runtime. When you write:

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

This function works with any object that has a name property. It doesn't care if the object came from a User class, a Person class, or a plain object literal. This is duck typing — "if it walks like a duck and quacks like a duck, it's a duck."

TypeScript's structural typing is the static analysis version of JavaScript's duck typing. It formalizes what JavaScript already does at runtime.

interface HasName {
  name: string;
}

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

// All of these work — they all have a name: string
greet({ name: "Alice" });
greet({ name: "Bob", age: 30 }); // Extra properties OK when passed from a variable
greet(new Employee("Carol")); // If Employee has name: string, it matches

class Dog {
  name: string;
  constructor(name: string) { this.name = name; }
}
greet(new Dog("Rex")); // A Dog has name: string — it matches HasName

type UserId = string & { readonly __brand: unique symbol };
type OrderId = string & { readonly __brand: unique symbol };

function getUser(id: UserId) { /* ... */ }

const userId = "abc" as UserId;
const orderId = "abc" as OrderId;

getUser(userId);  // OK
getUser(orderId); // ERROR — OrderId is not assignable to UserId

Excess Property Checking — The Exception That Confuses Everyone

There's one place where TypeScript appears to use nominal typing: object literal assignments:

interface Config {
  host: string;
  port: number;
}

// Direct object literal — excess property check kicks in
const config: Config = {
  host: "localhost",
  port: 3000,
  timeout: 5000, // ERROR: Object literal may only specify known properties
};

// Via a variable — no excess property check
const raw = { host: "localhost", port: 3000, timeout: 5000 };
const config2: Config = raw; // OK — has host and port, extra properties ignored

Structural Typing in Practice — Production Scenario

Consider a React component library where different components accept overlapping props:

interface Clickable {
  onClick: () => void;
  disabled?: boolean;
}

interface Hoverable {
  onMouseEnter: () => void;
  onMouseLeave: () => void;
}

interface ButtonProps extends Clickable, Hoverable {
  label: string;
  variant: "primary" | "secondary";
}

// A tracking wrapper that only cares about click behavior
function withClickTracking<T extends Clickable>(
  Component: React.ComponentType<T>,
  trackingId: string
) {
  return function TrackedComponent(props: T) {
    const trackedClick = () => {
      analytics.track(trackingId);
      props.onClick();
    };
    return <Component {...props} onClick={trackedClick} />;
  };
}

// Works with Button, Link, Card — anything with onClick + disabled?
const TrackedButton = withClickTracking(Button, "hero-cta");

The Clickable constraint doesn't care about the concrete type. Any component with onClick and optional disabled matches. This is structural typing enabling real composition.

Branded Types for Type Safety

type UserId = string & { readonly __brand: unique symbol };
type PostId = string & { readonly __brand: unique symbol };

function getUser(id: UserId) {
  return { id, name: "Alice" };
}

function getPost(id: PostId) {
  return { id, title: "Hello World" };
}

const userId = "u_123" as UserId;
const postId = "p_456" as PostId;

getUser(userId);  // OK
getPost(postId);  // OK
// getUser(postId); // ERROR: PostId is not assignable to UserId
// getPost(userId); // ERROR: UserId is not assignable to PostId