type vs. interface

Was beide gemeinsam haben

In den meisten Alltagsfällen sind type und interface deckungsgleich. Beide definieren Objektformen, beide unterstützen Generics, beide lassen sich von Klassen implementieren, beide erlauben Erweiterung — nur mit unterschiedlicher Syntax.

interface I_User {
    id: number;
    name: string;
}

type T_User = {
    id: number;
    name: string;
};

// Beide sind strukturell austauschbar:
const a: I_User = { id: 1, name: "Anna" };
const b: T_User = a;   // + ok
const c: I_User = b;   // + ok

Auch Generics sehen nahezu gleich aus.

interface I_Box<T> {
    value: T;
}

type T_Box<T> = {
    value: T;
};

const x: I_Box<string> = { value: "hi" };
const y: T_Box<number> = { value: 42 };

Eine Klasse kann gegen beide Varianten implementieren — der Compiler unterscheidet hier nicht.

interface I_Greeter { greet(): void; }
type T_Greeter = { greet(): void };

class A implements I_Greeter {
    greet() { console.log("hi"); }
}

class B implements T_Greeter {
    greet() { console.log("hi"); }
}

Was nur interface kann

Der prominenteste Unterschied: Declaration Merging. Wird ein interface mit demselben Namen mehrfach deklariert, fasst TypeScript die Properties zu einer einzigen Definition zusammen. Mit type ist das ein harter Fehler.

interface I_Config {
    host: string;
}

interface I_Config {
    port: number;
}

// beide Deklarationen werden gemerged:
const cfg: I_Config = { host: "localhost", port: 8080 };

Versucht man dasselbe mit type, blockiert der Compiler sofort.

type T_Config = { host: string };
type T_Config = { port: number };   // − Fehler: Duplicate identifier

Aus Declaration Merging folgt Module Augmentation — die Fähigkeit, fremde Typen aus Drittpaketen oder dem globalen Scope nachträglich zu erweitern. Klassischer Anwendungsfall: zusätzliche Properties am Window-Objekt deklarieren.

declare global {
    interface Window {
        __APP_VERSION__: string;
        analytics: { track(event: string): void };
    }
}

window.__APP_VERSION__ = "1.4.2";   // + jetzt typisiert

Auch ein Modul lässt sich von außen erweitern — etwa um eine fremde Bibliothek mit zusätzlichen Methoden auszustatten.

import "express";

declare module "express" {
    interface Request {
        requestId: string;
    }
}

Ein weiterer, oft übersehener Vorteil: bei sehr großen, tief verschachtelten Strukturen zeigt der TypeScript-Hover die Form eines interface meist mit Namen an, während ein type in eine inline-Struktur aufgelöst werden kann. In Fehlermeldungen erscheint die interface-Variante häufig benannt — bei der Suche nach Bugs in tiefen Generics ein Unterschied, der zählt.

Was nur type kann

Der type-Alias ist das vielseitigere Konstrukt. Alles, was kein reines Objekt-Shape ist, gehört in seine Domäne: Unions, Intersections, Tuples, Mapped Types, Conditional Types, Template Literal Types und typeof-Ableitungen.

type T_Status = "idle" | "loading" | "ready" | "error";
type T_Id = number | string;

type T_Point = [number, number];
type T_Named = { name: string };
type T_Aged = { age: number };
type T_Person = T_Named & T_Aged;

Mapped Types und Conditional Types sind reines type-Territorium — interface kann diese Konstrukte syntaktisch gar nicht ausdrücken.

type T_Optional<T> = {
    [K in keyof T]?: T[K];
};

type T_PartialUser = T_Optional<{ id: number; name: string }>;
// { id?: number; name?: string }

type T_NonNullable<T> = T extends null | undefined ? never : T;
type T_Clean = T_NonNullable<string | null>;   // string

Template Literal Types und typeof-Ableitungen runden das Bild ab.

type T_HttpVerb = "GET" | "POST" | "PUT" | "DELETE";
type T_Route = `/${string}`;
type T_Call = `${T_HttpVerb} ${T_Route}`;

const config = { host: "localhost", port: 8080 } as const;
type T_Config = typeof config;   // { readonly host: "localhost"; readonly port: 8080 }

Direkter Vergleich

Die folgende Tabelle fasst die Unterschiede in einer Übersicht zusammen.

Der einzige Bereich, in dem interface mehr kann als type, betrifft das Merging. Im Gegenzug ist type in fast jedem anderen Aspekt der mächtigere Begriff.

Strukturelle Kompatibilität

TypeScript prüft Typen strukturell — der Name spielt für die Kompatibilität keine Rolle. Solange die Form passt, sind type und interface in der Praxis vollständig austauschbar. Ein interface I_User und ein type T_User mit identischen Properties sind wechselseitig zuweisbar — auch über Modulgrenzen hinweg.

interface I_User {
    id: number;
    name: string;
}

type T_User = {
    id: number;
    name: string;
};

function greet(u: I_User): void {
    console.log(u.name);
}

const x: T_User = { id: 1, name: "Anna" };
greet(x);   // + ok — strukturell identisch

Wer eine API gemischt aus beiden Konstrukten baut, wird in der Anwendung keinen Unterschied bemerken. Die Wahl ist also eher eine Frage von Ergonomie und Erweiterbarkeit als von Korrektheit.

Empfehlung der TypeScript-Community

Das offizielle TypeScript-Team formuliert die Empfehlung pragmatisch: „Use interface until you need features from type." Dahinter steht keine Ideologie, sondern eine schlichte Beobachtung — interface deckt den häufigsten Fall (Objekt-Shapes) ab und bietet mit Declaration Merging die Tür zur Erweiterbarkeit. Sobald Unions, Mapped Types oder Conditional Types ins Spiel kommen, ist type alternativlos.

Eine praxistaugliche Faustregel:

• Public-API-Verträge (exportierte Typen, die Konsumenten kennen oder erweitern sollen): interface
• Interne Kombinatorik (Helper-Typen, Unions, Mapped Types): type
• Globale oder Drittparteien-Erweiterungen: zwingend interface

Diese Regel ist kein Dogma. In vielen Codebases — besonders kleineren — wird konsequent nur type verwendet, ohne dass irgendetwas verloren ginge. Konsistenz innerhalb eines Projekts ist wichtiger als die Wahl selbst.

Praxis-Beispiele

Eine Bibliothek exportiert ihre Public-API-Typen idealerweise als interface — so können Konsumenten sie via Module Augmentation erweitern.

// lib/types.ts
export interface I_RequestContext {
    url: string;
    method: "GET" | "POST" | "PUT" | "DELETE";
    headers: Record<string, string>;
}

// app.ts — Konsument fügt Felder hinzu
declare module "lib/types" {
    interface I_RequestContext {
        userId?: string;
        traceId?: string;
    }
}

Interne Helper-Typen — abgeleitet, gemappt, kombiniert — bleiben sauber im type-Land.

type T_ApiResult<T> =
    | { status: "ok"; data: T }
    | { status: "error"; message: string };

type T_Keys<T> = keyof T;
type T_ValueOf<T> = T[keyof T];

type T_PartialDeep<T> = {
    [K in keyof T]?: T[K] extends object ? T_PartialDeep<T[K]> : T[K];
};

Migration zwischen beiden

Der Wechsel von interface zu type und zurück ist meist trivial — solange die Form ein reines Objekt ist.

// vorher
interface I_User {
    id: number;
    name: string;
}

// nachher
type T_User = {
    id: number;
    name: string;
};

Bei extends-Ketten wird aus jedem extends eine Intersection.

// vorher
interface I_Named { name: string; }
interface I_Aged { age: number; }
interface I_Person extends I_Named, I_Aged {
    id: number;
}

// nachher
type T_Named = { name: string };
type T_Aged = { age: number };
type T_Person = T_Named & T_Aged & { id: number };

Was beim Wechsel von interface zu type verloren geht: die Fähigkeit, die Definition später zu mergen oder per Module Augmentation zu erweitern. Wer einen exportierten Public-API-Typ migriert, sollte sicher sein, dass kein Konsument darauf angewiesen ist.

Umgekehrt — von type zu interface — ist die Migration nur möglich, wenn der type wirklich ein reines Objekt-Shape ist. Unions, Tuples und Mapped Types lassen sich nicht in interface übersetzen.

Performance

Im Compiler-Innenleben gibt es einen kleinen, oft zitierten Unterschied: interface-Vererbung via extends ist marginal schneller zu prüfen als die äquivalente Intersection bei type. Der Grund ist, dass extends-Beziehungen einmal aufgelöst und gecached werden, während Intersections bei jeder Prüfung neu berechnet werden können.

In Zahlen: der Unterschied bewegt sich in der Größenordnung von Mikrosekunden pro Prüfung. In einer durchschnittlichen Codebase ist das vollkommen irrelevant. Erst in sehr großen Projekten mit Tausenden tief verschachtelter Typen kann es messbar werden — und auch dort selten zur Engstelle. Das offizielle Performance-Wiki von TypeScript empfiehlt interface extends gegenüber type mit Intersection in heißen Pfaden, räumt aber ein, dass die Auswirkung in der Praxis fast immer vernachlässigbar bleibt.

// marginal schneller im Compiler:
interface I_A { a: number; }
interface I_B extends I_A { b: number; }

// marginal langsamer:
type T_A = { a: number };
type T_B = T_A & { b: number };

Wer auf Performance optimiert, sollte zuerst andere Hebel prüfen — skipLibCheck, Project References, incremental — bevor er einzelne type-Definitionen in interface überführt.

Weiterführende Ressourcen

Externe Quellen

• Differences between Type Aliases and Interfaces
• Declaration Merging – TypeScript Handbook
• Performance – TypeScript Wiki

Verwandte Artikel

• Interfaces – Grundlagen
• Type System – Übersicht
• Aliase und Namenstypen
• Komplexe Typen – Übersicht
• Utility Types – Übersicht