TypeScript für Python-Entwickler: Konzepte und Unterschiede verständlich erklärt

1. Typsystem-Philosophie: strukturell statt nominal

Pythons Typsystem, auch mit mypy, orientiert sich stark an nominalen Typen und an Protocols für strukturelle Kompatibilität als bewusste Ausnahme. Eine Klasse ist grundsätzlich nur mit sich selbst oder ihren expliziten Basisklassen kompatibel, sofern kein Protocol im Spiel ist.

TypeScript kehrt dieses Verhältnis um: Kompatibilität basiert standardmäßig auf der Form eines Typs, nicht auf seinem Namen. Zwei Objekttypen mit identischen Properties gelten als kompatibel, selbst wenn sie in völlig unterschiedlichen Interfaces deklariert wurden.

Diese sogenannte strukturelle Typisierung, auch Duck Typing auf Typebene genannt, bedeutet: Wenn es aussieht wie ein User und sich verhält wie ein User, ist es für TypeScript ein User, unabhängig vom tatsächlichen Klassennamen oder Interface.

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

interface Employee {
  id: number;
  name: string;
  department: string;
}

function greet(user: User) {
  console.log(`Hallo, ${user.name}`);
}

const employee: Employee = { id: 1, name: "Alex", department: "IT" };
greet(employee); // erlaubt: Employee erfüllt strukturell die User-Form

2. Syntax-Grundlagen: Variablen, Funktionen, Klassen

Wo Python Typannotationen mit einem Doppelpunkt nach dem Namen schreibt, etwa def greet(name: str) -> str:, sieht TypeScript sehr ähnlich aus: function greet(name: string): string. Die grundlegende Syntaxposition der Annotation ist praktisch identisch.

Ein wichtiger Unterschied liegt bei Variablendeklarationen: Python-Typannotationen wie count: int = 0 sind rein dokumentarisch und werden von der Laufzeit ignoriert, während TypeScript-Annotationen vom Compiler tatsächlich gegen jede spätere Zuweisung geprüft werden, allerdings ebenfalls nur zur Compile-Zeit.

Klassen ähneln sich strukturell, aber TypeScript kennt zusätzlich interface und type als eigenständige, rein typebene Konstrukte ohne Laufzeit-Gegenstück, während Python für vergleichbare Zwecke Protocol und TypedDict aus dem typing-Modul nutzt.

3. Interfaces und Types vs. Protocols und Dataclasses

Ein TypeScript-interface beschreibt eine Objektform und lässt sich über extends erweitern, ähnlich wie Pythons Protocol-Klassen aus typing, die strukturelle Typprüfung erst nachträglich ins nominale Python-Typsystem eingeführt haben.

Pythons @dataclass-Decorator erzeugt automatisch Konstruktor, __repr__ und Vergleichsmethoden aus Feldannotationen. TypeScript hat kein direktes Äquivalent, weil interface und type reine Compile-Zeit-Konstrukte sind und keinen Laufzeitcode erzeugen, den ein Objektliteral bei der Erstellung durchläuft.

Der Unterschied ist erkennbar: Ein TypeScript-Objekt, das ein Interface erfüllt, existiert zur Laufzeit als reines JavaScript-Objekt ohne Klasseninformation, während eine Python-Dataclass-Instanz weiterhin über isinstance() und Reflection zur Laufzeit identifizierbar bleibt.

4. Optional[T]/None vs. undefined und null

Python kennt genau einen Abwesenheitswert, None, und drückt Optionalität über Optional[T] beziehungsweise T | None aus. TypeScript kennt dagegen zwei getrennte Werte: undefined für nicht gesetzte Werte und null für bewusst leere Werte.

Mit aktivierter strictNullChecks-Option, die in modernen Projekten praktisch immer aktiv sein sollte, muss jede Stelle, an der undefined oder null möglich ist, explizit im Typ vermerkt werden, sonst meldet der Compiler einen Fehler bei potenziellem Zugriff.

Optional Chaining über ?. und der Nullish-Coalescing-Operator ?? übernehmen in TypeScript die Rolle, die in Python häufig durch if value is not None:-Blöcke oder value or default-Ausdrücke abgedeckt wird, mit dem Unterschied, dass ?? anders als or nur auf null/undefined reagiert, nicht auf jeden falsy Wert.

interface Config {
  timeout?: number; // entspricht Optional[int] = None in Python
}

function getTimeout(config: Config): number {
  return config.timeout ?? 30_000; // nur bei null/undefined der Fallback
}

5. Generics: TypeVar vs. TypeScript-Generics

Pythons generische Typen basieren seit typing.TypeVar beziehungsweise der neueren class Stack[T]-Syntax ab Python 3.12 auf einem ähnlichen Grundprinzip wie TypeScript: Ein Platzhaltertyp wird an konkrete Aufrufe gebunden.

TypeScript geht bei Constraints weiter verbreitet in den Alltag über: <T extends { id: number }> schränkt einen generischen Typ direkt auf Objektformen mit bestimmten Properties ein, vergleichbar mit einem Python-Protocol als Bound für eine TypeVar, aber syntaktisch kompakter direkt in der Signatur.

Ein praktischer Unterschied: TypeScript-Generics existieren ausschließlich zur Compile-Zeit und werden beim Kompilieren vollständig entfernt, während Pythons Typannotationen zur Laufzeit über __class_getitem__ theoretisch inspizierbar bleiben, auch wenn davon in der Praxis selten Gebrauch gemacht wird.

function firstWithId<T extends { id: number }>(items: T[]): T | undefined {
  return items.find((item) => item.id > 0);
}

6. async/await: Event Loop statt asyncio-Event-Loop

Beide Sprachen nutzen dieselbe async/await-Syntax, aber die zugrunde liegenden Modelle unterscheiden sich: JavaScript und damit TypeScript sind grundsätzlich single-threaded mit einem eingebauten Event Loop, während Python zusätzlich echten Multithreading und Multiprocessing als Alternativen zu asyncio kennt.

In TypeScript ist praktisch jede I/O-Operation, von fetch bis Dateizugriff in Node.js, standardmäßig asynchron und gibt ein Promise<T> zurück. In Python bleibt asyncio eine bewusste Wahl neben synchronem Code, nicht die Grundannahme der gesamten Standardbibliothek.

Fehlerbehandlung funktioniert in beiden Sprachen über try/catch beziehungsweise try/except um ein await-Statement, allerdings kennt TypeScript kein Äquivalent zu Pythons asyncio.gather() mit benannten Task-Groups; stattdessen übernimmt Promise.all() beziehungsweise Promise.allSettled() diese Rolle.

7. Tooling-Vergleich: tsc vs. mypy, npm vs. pip

mypy ist ein optionales, nachträglich installiertes Werkzeug für ein Typsystem, das primär auf Compile-Zeit-Feedback zielt und den Code selbst niemals verändert. Der TypeScript-Compiler tsc übernimmt dieselbe Rolle, ist aber gleichzeitig auch der Transpiler, der aus TypeScript ausführbares JavaScript erzeugt.

Wo Python mit pip, Poetry oder uv um die beste Paketverwaltung konkurriert, hat sich im TypeScript-Ökosystem npm als Standard etabliert, ergänzt durch pnpm oder Yarn für striktere Dependency-Auflösung, jeweils mit demselben package.json-Format.

Virtuelle Umgebungen haben in TypeScript kein direktes Gegenstück, weil node_modules ohnehin projektlokal ist. Das Problem inkompatibler globaler Pakete, das venv in Python löst, existiert in der Node.js-Welt strukturell praktisch nicht.

8. Enums und Union Types vs. Python Enum und Literal

Pythons Enum-Klasse aus dem enum-Modul erzeugt echte, zur Laufzeit inspizierbare Objekte mit Namen und Wert. TypeScripts enum-Schlüsselwort erzeugt ebenfalls Laufzeitcode, wird aber in modernen Codebasen zunehmend zugunsten von Union Types aus String-Literalen gemieden.

Pythons Literal["pending", "shipped"] aus typing entspricht TypeScripts "pending" | "shipped" nahezu eins zu eins in der Bedeutung, mit dem Unterschied, dass TypeScript diese Union-Syntax nativ und ohne Import verwendet, während Python dafür explizit Literal importieren muss.

In beiden Sprachen ermöglicht diese Art von Typ eine erschöpfende Prüfung: mypys assert_never und TypeScripts never-Typ in einem switch-default-Zweig erfüllen dieselbe Aufgabe, nämlich sicherzustellen, dass jeder Fall einer Union tatsächlich behandelt wird.

9. Ökosystem und typische Einsatzgebiete im Vergleich

TypeScript dominiert im Frontend praktisch konkurrenzlos, weil JavaScript die einzige native Sprache im Browser ist. Für Backend-Dienste konkurriert es dort direkt mit Node.js-Alternativen, während Python im selben Bereich vor allem durch FastAPI, Django und Flask stark vertreten ist.

Im Data-Science- und Machine-Learning-Bereich bleibt Python praktisch alternativlos, während TypeScript dort höchstens für Tooling rund um Datenpipelines oder Frontend-Dashboards auftaucht, nicht für das eigentliche Modelltraining.

Für Full-Stack-Teams, die ohnehin TypeScript im Frontend einsetzen, liegt der Umstieg auf TypeScript im Backend über Node.js oder Deno nahe, um Typdefinitionen zwischen Client und Server zu teilen, ein Vorteil, den eine gemischte Python-plus-TypeScript-Architektur naturgemäß nicht bietet.

10. Zusammenfassung

11. FAQ: TypeScript für Python-Entwickler