Angenommen, ein Backend-Team, das seit Jahren Spring-Anwendungen in Java baut, soll künftig auch das Web-Frontend und ein paar Node.js-Dienste betreuen. Der erste Blick auf TypeScript wirkt beruhigend vertraut: Klassen, Interfaces, Generics, Zugriffsmodifizierer. Der zweite Blick irritiert. Ein Objekt passt zu einem Interface, das es nie implementiert hat. Ein instanceof auf ein Interface lässt sich nicht schreiben. Und zur Laufzeit ist von all den sorgfältig gepflegten Typen nichts mehr übrig.

Diese Irritation ist der beste Einstieg in TypeScript. Die Sprache sieht aus wie Java oder C#, folgt aber einer anderen Idee: Sie beschreibt JavaScript, statt es zu ersetzen. Wer das verstanden hat, versteht auch, warum TypeScript-Code auf so unterschiedliche Weise ausgeführt wird, warum Importe manchmal auf .js enden und warum Bibliotheken als zwei Dateien ausgeliefert werden. Das gilt für Umsteiger aus Java ebenso wie für JavaScript-Entwickler, die zum ersten Mal Typen schreiben.

TypeScript in einem Satz: JavaScript mit Typen, die vor dem Start verschwinden

Vereinfacht gesagt ist TypeScript JavaScript plus Typsyntax. Ganz präzise ist das nicht, denn es gibt einige Sprachmittel, die über reine Typangaben hinausgehen. Als Arbeitsmodell taugt der Satz aber. Ein Beispiel:

function add(x: number, y: number): number {
  return x + y;
}

Damit eine JavaScript-Engine diesen Code ausführen kann, muss die Typsyntax entfernt werden. Übrig bleibt gewöhnliches JavaScript:

function add(x, y) {
  return x + y;
}

Die Typen leisten ihre Arbeit also vorher: im Editor, während Sie tippen, und beim Prüflauf des Compilers. Sie melden, wenn jemand add('3', 4) aufruft, sie ermöglichen eine verlässliche Autovervollständigung, und sie machen Umbenennungen über Hunderte Dateien hinweg sicher. An der Ausführung selbst ändern sie nichts. Ein TypeScript-Programm ist zur Laufzeit genauso schnell oder langsam wie das JavaScript, das daraus entsteht.

Genau hier liegt der wichtigste Unterschied zu Java. Dort sind Typen Teil des Programms, die virtuelle Maschine kennt Klassen, prüft Casts und wirft eine ClassCastException, wenn etwas nicht passt. In TypeScript gibt es diese zweite Verteidigungslinie nicht. Was der Compiler nicht findet, findet zur Laufzeit niemand.

Was Java-Entwickler an TypeScript umlernen müssen

Wer aus Java kommt, bringt viel Nützliches mit: Denken in Schnittstellen, Gefühl für Generics, Disziplin bei der Modellierung. Einige Gewohnheiten führen aber in die Irre.

Strukturelle statt nominaler Typen

Java prüft Typen nominal: Eine Klasse ist nur dann ein Comparable, wenn sie das ausdrücklich erklärt. TypeScript prüft strukturell, es zählt allein die Form eines Objekts. Hat ein Objekt alle geforderten Eigenschaften mit passenden Typen, ist es kompatibel, ganz gleich, woher es stammt.

interface Kunde {
  id: string;
  name: string;
}

// Kein "implements" nötig: Die Form entscheidet.
const ausApi = { id: 'K-1001', name: 'Müller GmbH', ort: 'Köln' };

function begruessen(kunde: Kunde): string {
  return `Guten Tag, ${kunde.name}`;
}

begruessen(ausApi); // erlaubt, das zusätzliche Feld "ort" stört nicht

Das passt zu JavaScript, in dem Objekte ständig ad hoc entstehen, etwa aus JSON-Antworten. Es hat aber eine Kehrseite: Zwei Typen mit derselben Form sind austauschbar. Eine KundenId und eine BestellId, beide als string modelliert, lassen sich versehentlich verwechseln. Wer das verhindern will, greift zu sogenannten Branded Types, einem Muster, bei dem ein unsichtbares Markierungsfeld die Typen unterscheidbar macht.

Keine Typen zur Laufzeit

Java kennt das Prinzip bereits von Generics: Eine List<String> ist zur Laufzeit nur noch eine List, man spricht von Type Erasure. TypeScript geht konsequent weiter und löscht alle Typen. Interfaces und Typaliase existieren nach der Übersetzung nicht mehr. Deshalb funktioniert instanceof nur mit Klassen, denn nur sie sind echte JavaScript-Objekte.

Praktisch heißt das: Daten, die von außen kommen, etwa aus einem Formular, einer REST-API oder einer Datei, sind für den Compiler zunächst unbekannt. Eine Typannotation behauptet nur, wie sie aussehen. Ob die Behauptung stimmt, muss Code zur Laufzeit prüfen. Dafür haben sich Validierungsbibliotheken wie Zod oder Valibot etabliert, die aus einem Schema sowohl die Prüfung als auch den passenden TypeScript-Typ ableiten.

Union-Typen, null und Narrowing

In Java kann jede Referenz null sein, und der Compiler hilft wenig dabei. TypeScript behandelt null und undefined bei aktivierter Option strictNullChecks (Teil von strict) als eigene Typen. Ein Wert, der fehlen darf, wird ausdrücklich als string | null deklariert, und der Compiler verlangt eine Prüfung, bevor Sie ihn verwenden.

Solche Union-Typen sind eines der stärksten Werkzeuge der Sprache. Kombiniert mit einem gemeinsamen Unterscheidungsfeld entstehen sogenannte Discriminated Unions, vergleichbar mit Sealed Interfaces und Pattern Matching in neueren Java-Versionen:

type Zahlung =
  | { art: 'rechnung'; zahlungszielTage: number }
  | { art: 'karte'; kartennummerEndung: string }
  | { art: 'paypal'; email: string };

function beschreibe(zahlung: Zahlung): string {
  switch (zahlung.art) {
    case 'rechnung':
      return `Zahlbar in ${zahlung.zahlungszielTage} Tagen`;
    case 'karte':
      return `Karte endet auf ${zahlung.kartennummerEndung}`;
    case 'paypal':
      return `PayPal-Konto ${zahlung.email}`;
  }
}

Innerhalb jedes case weiß der Compiler, welche Variante vorliegt, und erlaubt nur die passenden Felder. Kommt später eine vierte Zahlungsart hinzu, meldet er die Funktion als unvollständig. Dieses Verengen eines Typs durch Prüfungen heißt Narrowing.

Klassen sind möglich, aber nicht der Normalfall

TypeScript unterstützt Klassen mit private, protected, abstrakten Methoden und Vererbung. Idiomatischer TypeScript-Code nutzt sie aber sparsamer als Java. Viele Module bestehen aus exportierten Funktionen und einfachen Datenobjekten. Wer jede Funktion in eine Service-Klasse packt, schreibt Java in TypeScript-Syntax, was funktioniert, aber umständlicher ist als nötig. Zwei weitere Details überraschen Umsteiger regelmäßig: Es gibt nur einen Zahlentyp number (eine 64-Bit-Gleitkommazahl) plus bigint für große Ganzzahlen, und Methodenüberladung im Java-Sinn existiert nicht, nur mehrere Signaturen für eine einzige Implementierung.

Drei Wege, TypeScript auszuführen

Weil die Typen vor der Ausführung verschwinden müssen, stellt sich bei jedem Projekt die Frage, wer sie entfernt. Heute gibt es dafür drei verbreitete Wege.

Direkt in Node.js, Deno und Bun

Deno und Bun führen TypeScript seit ihren ersten Versionen direkt aus. Node.js hat nachgezogen: Seit Version 23.6 ist das sogenannte Type Stripping standardmäßig aktiv, in die Langzeitlinie Node.js 22 kam es mit Version 22.18. Node.js 24 bringt es ebenfalls ohne Zusatzschalter mit. Ein Aufruf genügt:

node src/main.ts

Node.js entfernt dabei nur die Typsyntax und prüft nichts. Typfehler fallen erst auf, wenn Sie den Compiler separat laufen lassen. Außerdem liest Node.js keine tsconfig.json und unterstützt nur Syntax, die sich rückstandslos löschen lässt. Dazu gleich mehr. Für Skripte, Werkzeuge und kleinere Dienste ist dieser Weg trotzdem eine deutliche Erleichterung, weil ein ganzer Build-Schritt entfällt.

Bündeln im Frontend

Browser verstehen kein TypeScript. Im Frontend übernimmt deshalb ein Bundler die Übersetzung, etwa Vite, esbuild, Rollup oder Webpack. Bündeln heißt, Anwendungs- und Bibliothekscode zu wenigen Dateien zusammenzufassen, die eine HTML-Seite lädt. Das lohnt sich auch ohne TypeScript: Der Browser muss weniger Dateien anfordern, große Dateien lassen sich besser komprimieren, und ungenutzter Code fliegt heraus.

Die meisten Bundler entfernen Typen sehr schnell, prüfen sie aber ebenfalls nicht. Vite etwa übersetzt jede Datei für sich und überlässt die Typprüfung dem Editor und einem separaten Lauf von tsc. Für Teams bedeutet das: Ein erfolgreicher Build ist noch kein Beweis für typkorrekten Code.

Übersetzen mit tsc

Der klassische Weg ist der offizielle Compiler tsc. Er übersetzt TypeScript-Dateien in JavaScript-Dateien, gesteuert über die tsconfig.json, in der unter anderem das Ausgabeverzeichnis steht, häufig dist/. Übersetzungen von Quellcode in anderen Quellcode nennt man Transpilieren. Die erzeugten Dateien spiegeln die Struktur des Projekts und laufen auf jeder JavaScript-Plattform. Dieser Weg ist am kompatibelsten und für Bibliotheken nach wie vor üblich, kostet aber einen zusätzlichen Schritt im Entwicklungszyklus.

Unabhängig vom gewählten Weg bleibt tsc das Werkzeug für die eigentliche Typprüfung. In vielen Projekten läuft es nur noch mit --noEmit, also ohne Ausgabe, als Prüfschritt im Editor-Workflow und in der CI-Pipeline.

Type Stripping: Welche Syntax beim schnellen Weg wegfällt

Type Stripping, also das bloße Löschen der Typsyntax, funktioniert nur, wenn nach dem Löschen gültiges JavaScript übrig bleibt. Einige ältere TypeScript-Sprachmittel erzeugen aber eigenen Laufzeitcode und lassen sich deshalb nicht einfach entfernen:

• Enums mit dem Schlüsselwort enum
• Namespaces mit Laufzeitcode
• Parameter Properties, also Konstruktorparameter wie constructor(private name: string), die automatisch Felder anlegen
• ältere Formen von import = und export =

JSX, die HTML-ähnliche Syntax aus React, gehört ebenfalls nicht zum reinen Type Stripping und braucht weiterhin einen Übersetzungsschritt. Seit TypeScript 5.8 gibt es die Compileroption erasableSyntaxOnly, die genau diese Konstrukte als Fehler meldet. Wer Code direkt in Node.js ausführen will, aktiviert sie und ersetzt etwa Enums durch konstante Objekte:

// Statt "enum Status { Offen, Bezahlt }":
export const Status = {
  Offen: 'offen',
  Bezahlt: 'bezahlt',
} as const;

export type Status = (typeof Status)[keyof typeof Status];
// Status ist damit 'offen' | 'bezahlt'

Eine elegante Idee stammt aus dem Werkzeug ts-blank-space, das Ashley Claymore bei Bloomberg entwickelt hat: Statt die Typen zu löschen, ersetzt es sie durch Leerzeichen. Zeilen und Spalten bleiben dadurch an derselben Stelle wie im Original. Fehlermeldungen und Stacktraces zeigen auf die richtige Position im TypeScript-Quelltext, ganz ohne Source Maps, also Zuordnungsdateien zwischen erzeugtem und ursprünglichem Code. Node.js verfährt beim Type Stripping nach demselben Prinzip.

Eine typische Konfiguration für Projekte, die Node.js direkt ausführt und tsc nur prüfen lässt, sieht so aus:

{
  "compilerOptions": {
    "target": "esnext",
    "module": "nodenext",
    "strict": true,
    "noEmit": true,
    "allowImportingTsExtensions": true,
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true
  }
}

Die Option verbatimModuleSyntax erzwingt, dass reine Typimporte als import type gekennzeichnet sind. So kann ein Werkzeug sie entfernen, ohne den Rest des Programms zu verstehen.

.ts oder .js: Dateiendungen in Importen

Eine der häufigsten Fragen in gemischten Teams betrifft die Endung in Importen. In Projekten, die mit tsc übersetzt werden, schreiben Sie traditionell:

// main.ts
import { helperFunc } from './util.js';

Das wirkt zunächst falsch, denn die Datei heißt util.ts. Der Grund: tsc lässt Modulpfade standardmäßig unverändert. Zur Laufzeit liegt aber die übersetzte util.js im Ausgabeverzeichnis, und auf genau diese Datei muss der Import zeigen. Dass Endungen überhaupt nötig sind, liegt an ECMAScript-Modulen (ESM): Anders als das ältere CommonJS ergänzen sie keine Endungen automatisch. Wie die Umstellung auf ESM gelingt, beschreibt unser Beitrag Von CommonJS zu ESM: Node.js-Projekte auf import umstellen.

Wird der Code dagegen direkt mit Node.js ausgeführt, muss der Import auf die echte Datei zeigen:

// main.ts
import { helperFunc } from './util.ts';

Damit beide Welten zusammenpassen, gibt es seit TypeScript 5.7 die Option rewriteRelativeImportExtensions. Sie schreibt relative Importe mit .ts bei der Übersetzung in .js um. Ein Projekt kann dann mit Node.js direkt laufen und trotzdem mit tsc gebaut werden. Wichtig ist vor allem, dass sich ein Team auf eine Variante festlegt.

Bibliotheken veröffentlichen: npm, Typdeklarationen und JSR

Bei eigenen Anwendungen haben Sie die Wahl der Laufzeit. Bei Bibliotheken nicht, denn sie sollen in beliebigen Projekten funktionieren, auch in reinem JavaScript.

Was ein npm-Paket enthält

Die npm-Registry ist weiterhin der wichtigste Verteilweg für JavaScript- und TypeScript-Pakete. Zudem führt Node.js TypeScript-Dateien innerhalb von node_modules bewusst nicht aus. Bibliotheken werden deshalb als JavaScript veröffentlicht, ergänzt um Typinformationen. Aus einer Quelldatei lib.ts entstehen typischerweise:

• lib.js mit dem ausführbaren JavaScript-Code
• lib.d.ts, eine Deklarationsdatei mit den reinen Typinformationen
• optional lib.js.map und lib.d.ts.map als Source Maps, die zurück auf lib.ts verweisen, sowie lib.ts selbst als Ziel dieser Verweise

Aus diesem Modul:

/** Addition zweier Zahlen. */
export function add(x: number, y: number): number {
  return x + y; // numerische Addition
}

erzeugt tsc die JavaScript-Datei:

/** Addition zweier Zahlen. */
export function add(x, y) {
  return x + y; // numerische Addition
}
//# sourceMappingURL=lib.js.map

und die Deklarationsdatei:

/** Addition zweier Zahlen. */
export declare function add(x: number, y: number): number;
//# sourceMappingURL=lib.d.ts.map

Die JavaScript-Datei behält alle Kommentare, die Deklarationsdatei nur JSDoc-Kommentare, die mit /** beginnen. Editoren zeigen sie als Dokumentation an, wenn Sie über einen Funktionsnamen fahren. JavaScript-Projekte ignorieren die .d.ts-Dateien, profitieren im Editor aber trotzdem davon, denn VS Code nutzt sie auch beim Bearbeiten von JavaScript für Vorschläge.

DefinitelyTyped für Pakete ohne Typen

Viele ältere Pakete bringen keine eigenen Typen mit. Für sie gibt es DefinitelyTyped, ein gemeinschaftlich gepflegtes Repository mit Deklarationsdateien. Zu einem Paket pkg installieren Sie dann zusätzlich @types/pkg als Entwicklungsabhängigkeit. Das wichtigste Beispiel ist @types/node mit den Typen der Node.js-Standardbibliothek, das in fast jedem Node.js-Projekt mit TypeScript steckt.

Isolierte Deklarationen

Deklarationsdateien zu erzeugen, war lange Aufgabe von tsc, weil dafür Typen abgeleitet werden müssen. Schnellere Werkzeuge können das nur, wenn der Code ihnen diese Arbeit abnimmt. Genau das verlangt die Option isolatedDeclarations, die TypeScript 5.5 eingeführt hat: Exportierte Funktionen und Werte brauchen explizite Typangaben, etwa für den Rückgabetyp. Nicht exportierte Funktionen sind ausgenommen, denn sie tauchen in Deklarationsdateien nicht auf. Für Java-Entwickler ist das ohnehin vertraut, und in großen Codebasen beschleunigt es Builds spürbar, weil sich Dateien unabhängig voneinander verarbeiten lassen.

JSR als Alternative zu npm

Seit 2024 gibt es mit JSR eine Registry, die TypeScript anders behandelt. Dort laden Sie die originalen .ts-Dateien hoch. Laufzeiten mit TypeScript-Unterstützung wie Deno erhalten genau diese Dateien. Für andere Umgebungen, etwa Node.js, erzeugt JSR beim Installieren selbst .js- und .d.ts-Dateien. Damit das zuverlässig klappt, verlangt JSR einen Stil namens „no slow types“, der den isolierten Deklarationen sehr ähnelt. Außerdem erstellt JSR aus den Typen und JSDoc-Kommentaren automatisch eine Dokumentationsseite.

Betrieben wird JSR vom Unternehmen hinter Deno. Laut den Betreibern soll das Projekt nicht dauerhaft von einer einzelnen Firma abhängen, geplant ist eine unabhängige Governance mit eigenem Gremium. Für Unternehmen ist JSR eine interessante Option für TypeScript-first-Pakete. Die Standardwahl bleibt für die meisten Teams aber npm, schon weil Werkzeuge, Sicherheitsscanner und private Registries darauf ausgerichtet sind.

Editor, Typprüfung und JSDoc im Teamalltag

Den größten Nutzen spüren Teams nicht beim Kompilieren, sondern beim Schreiben von Code.

VS Code und WebStorm

Visual Studio Code, der kostenlose Editor von Microsoft, ist selbst größtenteils in TypeScript geschrieben und unterstützt die Sprache ohne Erweiterungen. Der wichtigste Unterschied zum Java-Alltag in IntelliJ: VS Code prüft standardmäßig nur die geöffneten Dateien, und zwar mit einer mitgelieferten TypeScript-Version, nicht unbedingt mit der des Projekts. Über die Befehlspalette lässt sich auf die Projektversion umschalten, was in Teams Verwirrung über abweichende Fehlermeldungen vermeidet.

Für die Prüfung der gesamten Codebasis muss tsc laufen, im Editor als Task, im Git-Hook oder in der CI-Pipeline. Bewährt hat sich die Kombination: sofortige Rückmeldung im Editor, vollständige Prüfung vor dem Merge.

WebStorm von JetBrains ist die naheliegende Alternative für Teams, die IntelliJ gewohnt sind, mit vergleichbarer Bedienung und eigenen Refactoring-Werkzeugen. Für die kommerzielle Nutzung ist eine Lizenz nötig, für nicht kommerzielle Zwecke bietet JetBrains seit 2024 eine kostenlose Variante an.

Ein schnellerer Compiler in Go

Bei großen Projekten dauerte ein vollständiger Prüflauf mit tsc lange spürbar. Microsoft kündigte deshalb 2025 an, Compiler und Sprachdienst nach Go zu portieren. Das Ergebnis ist TypeScript 7, erschienen im Juli 2026: ein nativer, in Go geschriebener Compiler, der laut Microsoft Builds etwa um den Faktor zehn beschleunigt. Vorausgegangen war TypeScript 6 als Übergangsversion, die veraltete Compileroptionen bereinigte. Wer eine große Codebasis aktualisiert, sollte vorher prüfen, ob alle Werkzeuge im Projekt die neue Hauptversion schon unterstützen. Eine Programmierschnittstelle des Compilers fehlt in Version 7.0 noch. Linter-Integrationen und andere Tools, die auf diese Schnittstelle zugreifen, laufen deshalb vorerst weiter mit TypeScript 6.

Typprüfung für JavaScript mit JSDoc

TypeScript kann auch reine JavaScript-Dateien prüfen, etwa mit // @ts-check am Dateianfang oder der Option checkJs. Typen geben Sie dann in JSDoc-Kommentaren an:

/**
 * @param {number} x - Der erste Operand
 * @param {number} y - Der zweite Operand
 * @returns {number} Die Summe beider Operanden
 */
function add(x, y) {
  return x + y;
}

Technisch ist das TypeScript in anderer Schreibweise. Der Ansatz hat echte Vorteile: Es gibt keinen Übersetzungsschritt, auch im Browser nicht, tsc kann aus solchen Dateien Deklarationsdateien erzeugen, und bestehende Codebasen lassen sich schrittweise absichern. Bei komplexen Typen wird die Syntax allerdings sperrig. Ein Interface:

interface Point {
  x: number;
  y: number;
  /** optionale Eigenschaft */
  z?: number;
}

sieht in JSDoc so aus:

/**
 * @typedef {object} Point
 * @property {number} x
 * @property {number} y
 * @property {number} [z] optionale Eigenschaft
 */

Für Bibliotheken, die ohne Build-Schritt auskommen sollen, oder als erster Schritt in einer gewachsenen JavaScript-Anwendung ist JSDoc eine gute Wahl. Für neue Projekte überwiegen meist die Vorteile echter .ts-Dateien. Wie ein Team den Umstieg Schritt für Schritt plant, zeigt der Beitrag TypeScript im JavaScript-Team einführen, eine Übersicht über Migrationsstrategien bietet die Infothek unter schrittweise Migration von JavaScript zu TypeScript.

Für wen sich TypeScript lohnt und wo die Grenzen liegen

TypeScript ist im Web-Umfeld längst Standard. Angular setzt es voraus, React-, Vue- und Svelte-Projekte starten in aller Regel damit, und auf dem Server ist es mit Node.js, Deno und Bun bequemer geworden als je zuvor. Für Teams aus der Java- oder C#-Welt ist es der kürzeste Weg, im Frontend mit vertrauten Mitteln wie Schnittstellen, Generics und Refactoring-Werkzeugen zu arbeiten.

Überschätzt wird allerdings die Sicherheit, die Typen bieten. TypeScript prüft Annahmen, keine Daten. Externe Eingaben brauchen Validierung zur Laufzeit, und Auswege wie any oder Typzusicherungen mit as setzen die Prüfung genau dort außer Kraft, wo sie am nötigsten wäre. Ein TypeScript-Projekt mit lockerer Konfiguration und vielen any vermittelt mehr Sicherheit, als es bietet. Unsere Empfehlung: strict von Anfang an einschalten, any in Code-Reviews ernst nehmen und tsc verbindlich in der CI-Pipeline laufen lassen.

Weniger lohnend ist TypeScript bei sehr kleinen Skripten oder Wegwerf-Prototypen. Seit Node.js Typen direkt entfernt, ist allerdings auch dort die Einstiegshürde gering geworden. Der wichtigste Rat für Umsteiger aus Java lautet: Nicht versuchen, Java nachzubauen. Wer strukturelle Typen, Union-Typen und das Fehlen von Laufzeittypen akzeptiert, schreibt schnell idiomatischen und gut wartbaren Code.

Wenn Sie TypeScript im Team einführen oder ein bestehendes Projekt umstellen möchten, finden Sie auf unserer Themenseite zu TypeScript-Beratung, Coaching und Seminaren Angebote vom Einstiegsseminar bis zur Begleitung größerer Migrationen.

Häufige Fragen zu TypeScript

Lässt sich TypeScript ohne Kompilierschritt verwenden?

Auf dem Server ja: Node.js ab Version 23.6 und 22.18, Deno und Bun führen .ts-Dateien direkt aus. Node.js entfernt dabei nur die Typen und unterstützt keine Syntax mit eigenem Laufzeitcode wie enum. Im Browser ist weiterhin ein Bundler oder Compiler nötig. Eine Alternative ohne jeden Build-Schritt ist JavaScript mit JSDoc-Typen, das TypeScript im Editor und in der CI prüft. Einen Vorschlag, Typannotationen direkt in JavaScript zu erlauben, gibt es beim Standardisierungsgremium TC39, er befindet sich aber noch in einem frühen Stadium.

Ist jeder JavaScript-Code auch gültiges TypeScript?

Syntaktisch fast immer. TypeScript wird oft als Obermenge von JavaScript bezeichnet, und eine .js-Datei lässt sich in der Regel in .ts umbenennen. Der Compiler meldet danach aber häufig Typfehler, etwa wenn eine Variable erst eine Zahl und später einen Text enthält. Diese Meldungen sind genau der Zweck des Umstiegs. Mit lockeren Einstellungen lässt sich der Übergang abfedern und die Prüfung schrittweise verschärfen.

Muss ein Projekt komplett auf einmal umgestellt werden?

Nein. TypeScript ist darauf ausgelegt, mit JavaScript im selben Projekt zusammenzuarbeiten. Typische Schritte sind: zuerst checkJs oder // @ts-check mit JSDoc-Typen, dann einzelne Module, die oft geändert werden oder besonders fehleranfällig sind, nach .ts umstellen, für eigene JavaScript-Module ohne Typen bei Bedarf Deklarationsdateien schreiben und zuletzt strict aktivieren. Größere Codebasen werden so über Wochen oder Monate umgestellt, ohne dass die Weiterentwicklung stillsteht.

Brauchen Java-Entwickler noch Klassen und Interfaces?

Interfaces sind in TypeScript sehr verbreitet, beschreiben aber nur Formen und keine Verträge, die eine Klasse ausdrücklich erfüllen muss. Für viele Fälle sind Typaliase mit type gleichwertig, bei Union-Typen sogar die einzige Möglichkeit. Klassen lohnen sich, wenn Zustand und Verhalten eng zusammengehören oder ein Framework wie Angular sie erwartet. Für reine Datenobjekte und zustandslose Logik genügen meist einfache Objekte und Funktionen.