3 Typsysteme, die kein TypeScript sind

TypeScript ist der Standardweg, um JavaScript zu typisieren, aber nicht der einzige. Wer schon einmal einen Build-Schritt in ein kleines Projekt eingebaut hat, nur um ein paar Typannotationen zu erhalten, oder dabei zugeschaut hat, wie tsc sich durch eine große Codebasis quält, hat sich wahrscheinlich gefragt, ob es einen leichteren Weg zu Typsicherheit gibt. Den gibt es – und sogar mehr als einen.

Die drei glaubwürdigsten Nicht-TypeScript-Typsysteme für JavaScript im Jahr 2026 sind JSDoc mit // @ts-check, ReScript und Flow: Eines bietet Typprüfung ohne Build-Schritt, eines liefert stärkere Garantien als TypeScript, und eines ist ein Legacy-Checker, den man nur zur Pflege bestehenden Codes übernehmen würde. Alles andere, was in „TypeScript-Alternativen”-Übersichten häufig aufgeführt wird (Deno, Dart, Kotlin/JS), ist eine Laufzeitumgebung oder eine plattformübergreifende Sprache – kein auf JavaScript aufgesetztes Typsystem.

Dies ist ein vergleichender Überblick für Entwickler, die TypeScript bereits kennen und die Abwägungen klar formuliert haben möchten: Sprache vs. Checker, Build-Schritt oder nicht, Soundness gegenüber TypeScripts bewusst unsoundem Modell sowie der aktuelle Stand des Ökosystems.

Die drei echten TypeScript-Alternativen im Jahr 2026

Ein echtes „Typsystem für JavaScript” prüft entweder Typen im JavaScript-Quellcode (ein Checker oder eine Annotationsschicht) oder kompiliert eine typisierte Sprache nach JavaScript. Diese Definition schließt JSDoc-plus-@ts-check, ReScript und Flow ein. Sie schließt Deno aus (eine Laufzeitumgebung, die zufällig TypeScript ausführt) sowie Dart und Kotlin/JS (eigenständige Sprachen, die JavaScript als eines von mehreren Kompilierungszielen ansteuern). Diese sind durchaus wissenswert, beantworten aber eine andere Frage.

Zum Hintergrund: Stand Mitte 2026 ist TypeScript 7.0 das aktuelle Stable Release. Es wurde am 8. Juli 2026 als nativer Go-Port des Compilers veröffentlicht, der laut Microsoft bei vollständigen Builds typischerweise 8- bis 12-mal schneller ist als TypeScript 6.0. TypeScript 6.0 war das letzte Release, das auf der alten JavaScript-Codebasis aufbaute – ein Übergang, dessen Typprüfungsverhalten 7.0 beibehält. Eine Lücke bleibt: 7.0 wird ohne eine stabile programmatische API ausgeliefert, sodass das Tooling für die Template-Typprüfung in Vue, Svelte und Angular auf TypeScript 7.1 warten muss, das für Oktober 2026 erwartet wird. Das ist relevant: Es beeinflusst, was für JSDoc im 7.0-Zeitalter weiterhin gilt.

JSDoc + @ts-check: TypeScripts Typsystem ohne den Build-Schritt

Was es ist: JSDoc-basiertes Typisieren ermöglicht es, einfache .js-Dateien mit strukturierten Kommentaren zu annotieren und sie mit exakt derselben Engine wie TypeScript zu prüfen: dem TypeScript Language Service. Dies ist vom Dokumentationsgenerator JSDoc zu unterscheiden; hier steuern die Annotationen die Typprüfung. Das TypeScript-Handbuch dokumentiert --checkJs als das Flag, das Fehler in .js-Dateien meldet – verfügbar seit TypeScript 2.3.

Wie man es einführt: Man fügt einen einzelnen Kommentar an den Anfang einer Datei ein oder setzt zwei tsconfig-Flags für das gesamte Projekt. VS Codes JavaScript-Dokumentation beschreibt // @ts-check als die Möglichkeit, einige Dateien zu prüfen, ohne es überall zu aktivieren.

// @ts-check

/**
 * @typedef {{ id: number, name: string }} User
 */

/**
 * @param {User} user
 * @returns {string}
 */
function greet(user) {
  return `Hi, ${user.name}`;
}

Für ein ganzes Projekt entfällt der dateiweise Kommentar:

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true
  }
}

Da JSDoc-Typen löschbare Kommentare sind, läuft die Datei als Standard-JavaScript in jedem Browser oder jeder Laufzeitumgebung ohne Kompilierungsschritt – weshalb man sie auch dateiweise einführen kann. Der Kompromiss: Man übernimmt TypeScripts Modell vollständig, einschließlich seiner bewussten Unsoundness, und die Annotationssyntax ist ausführlicher als in .ts-Dateien. Ein wichtiger Hinweis für die 7.0-Ära: Microsoft hat die JavaScript-Typprüfung für TypeScript 7.0 von Grund auf neu geschrieben und einige weniger genutzte Tags entfernt – TypeScript 7.0 erkennt die Tags @enum und @constructor nicht mehr.

Wann man es wählt: Man möchte inkrementelle Typsicherheit für eine bestehende JavaScript-Codebasis oder eine Bibliothek, die einfaches JS ausliefert, ohne einen Kompilierungsschritt einzuführen.

ReScript: sound, nominal, vollständig inferiert

Was es ist: ReScript ist eine eigenständige Compile-to-JavaScript-Sprache, keine Annotationsschicht, mit einem von OCaml übernommenen Typsystem. TypeScripts Typsystem ist bewusst unsound: Es akzeptiert einige fehlerhafte Programme, um mit JavaScripts Laufzeitsemantik kompatibel zu bleiben. Genau diese Lücke schließt ReScript: Es ist vollständig inferiert und hat, wie das Projekt es formuliert, kein any, keine magischen Typen, kein überraschendes undefined. Im Gegensatz zu TypeScripts strukturellem Typsystem, bei dem jedes Objekt mit der richtigen Form einen Typ erfüllt, sind ReScripts Records und Variants nominal – zwei strukturell identische Typen sind also nicht austauschbar, sofern dies nicht explizit deklariert wurde.

Wie man es einführt: Man installiert den Compiler und konfiguriert rescript.json, die einzige, obligatorische Build-Datei für ein ReScript-Projekt (in Versionen vor ReScript 11 war es bsconfig.json). ReScript 12, veröffentlicht am 25. November 2025, entfernt die Unterstützung für bsconfig.json vollständig und verwendet standardmäßig ES-Module als Modulausgabe.

{
  "name": "my-app",
  "sources": { "dir": "src", "subdirs": true },
  "package-specs": { "module": "esmodule", "in-source": true },
  "suffix": ".res.js"
}

Das Suffix der generierten JS-Dateien kann frei gewählt werden; das Team empfiehlt .res.js oder .res.mjs, was auch die offiziellen create-rescript-app-Templates verwenden. Ein minimales Modul:

let add = (a: int, b: int): int => a + b
let result = add(1, 2)
Console.log(result)

Die Kosten sind real: Es ist eine andere Sprache mit eigener Syntax, man schreibt Interop-Bindings, um JavaScript-Bibliotheken zu nutzen, und das Ökosystem ist deutlich kleiner als das von TypeScript. ReScript wurde jedoch mit schrittweiser Einführung im Sinn entwickelt: Möchte man jemals zu einfachem JavaScript zurückkehren, entfernt man die Quelldateien und behält die saubere JavaScript-Ausgabe.

Wann man es wählt: Ein Greenfield-Projekt, bei dem man die stärkstmöglichen Typgarantien möchte und bereit ist, sich auf eine Sprache – nicht nur auf Annotationen – einzulassen.

Flow: noch vorhanden, weitgehend überholt

Was es ist: Flow ist ein quelloffener statischer Typchecker für JavaScript, entwickelt von Facebook/Meta und in OCaml geschrieben. Wie Flow stammt auch ReScript von OCaml ab, aber die beiden befinden sich heute an entgegengesetzten Enden der Verbreitung. Flow ist ein Checker, keine Sprache: Man annotiert .js-Dateien, markiert sie mit // @flow und entfernt die Typen zur Build-Zeit mit Babel.

// @flow
function add(a: number, b: number): number {
  return a + b;
}

Verbreitungsrealität im Jahr 2026: Flow ist intern bei Meta in Millionen von JavaScript- und React-Dateien im Einsatz, aber sein externes Ökosystem hat sich deutlich verkleinert: weniger Bibliotheksdefinitionen, weniger Tutorials und dünneres Tooling als bei TypeScript. Die Migration großer Meta-naher Projekte von Flow zu TypeScript wurde in der Community diskutiert, ohne dass eine primäre Quelle einen konkreten Plan bestätigt. Ältere Vergleiche, die Flow eine glänzende Zukunft attestieren, sind veraltet; der Schwung hat sich vor Jahren zu TypeScript verlagert.

Wann man es wählt: Realistisch betrachtet nur dann, wenn man eine bestehende Flow-Codebasis pflegt. Für alles Neue sind die anderen beiden Optionen die bessere Wahl.

Fazit: Das Werkzeug zur Situation passend wählen

JSDoc mit @ts-check ist die richtige Wahl, wenn man inkrementelles Typisieren ohne Build-Tooling und volle Kompatibilität mit einfachem JavaScript möchte. Es ist die am meisten unterschätzte und praktischste Lösung, da es TypeScripts eigener Checker ist, der auf .js-Dateien angewendet wird. ReScript wählt man, wenn man von Grund auf neu startet und maximale Typsoundness möchte und dabei eine separate Sprache sowie Interop-Bindings als Preis akzeptiert. Flow behält man nur zur Pflege von bereits darin geschriebenem Code. Wer heute Typsicherheit ohne Verlassen von JavaScript möchte, fügt // @ts-check zu einer Datei hinzu und beobachtet, welche Fehler auftauchen.

Häufig gestellte Fragen

Kann man JSDoc-Typprüfung verwenden, ohne TypeScript als Abhängigkeit zu installieren?

Editoren wie VS Code liefern den TypeScript Language Service bereits eingebaut, sodass das Hinzufügen von // @ts-check zu einer .js-Datei Typprüfung ohne npm install ermöglicht. Um dieselbe Prüfung auf der Kommandozeile oder in CI auszuführen, installiert man das typescript-Paket und führt tsc mit aktivierten Flags allowJs und checkJs aus. Die Typen selbst verbleiben in JSDoc-Kommentaren, sodass dem ausgelieferten JavaScript in keinem Fall etwas hinzugefügt wird.

Was ist der Unterschied zwischen strukturellem Typisieren in TypeScript und nominalem Typisieren in ReScript?

Strukturelles Typisieren, wie es TypeScript verwendet, behandelt jedes Objekt mit der richtigen Form als Erfüllung eines Typs – zwei unverwandte Typen mit identischen Feldern sind also austauschbar. ReScripts Records und Variants sind nominal, was bedeutet, dass zwei strukturell identische Typen als unterschiedlich behandelt werden, sofern keine explizite Beziehung deklariert wurde. Nominales Typisieren verhindert die versehentliche Substitution von ähnlich aussehenden Typen, was ein Grund dafür ist, dass ReScripts System sound ist, während TypeScripts bewusst unsound ist.

Warum wird Deno in diesem Vergleich nicht als TypeScript-Alternative betrachtet?

Deno ist eine JavaScript- und TypeScript-Laufzeitumgebung, kein auf JavaScript aufgesetztes Typsystem. Es führt TypeScript direkt aus, indem es den TypeScript-Compiler bündelt – es ist also von TypeScript abhängig, anstatt es zu ersetzen. Eine echte Alternative muss entweder Typen im JavaScript-Quellcode prüfen oder eine typisierte Sprache nach JavaScript kompilieren. Dieselbe Überlegung schließt Dart und Kotlin/JS aus, die eigenständige Sprachen sind und JavaScript als eines von mehreren Kompilierungszielen ansteuern.

Bricht der Wechsel zu TypeScript 7.0 bestehende JSDoc-typisierte JavaScript-Projekte?

Größtenteils nicht, aber das Go-basierte TypeScript 7.0 hat die JavaScript-Typprüfung von Grund auf neu geschrieben und einige weniger genutzte JSDoc-Tags entfernt – konkret @enum und @constructor, die 7.0 nicht mehr erkennt. Projekte, die auf diese Tags angewiesen sind, müssen sie auf unterstützte Muster migrieren. Gängige Tags wie @param, @returns, @typedef und @template funktionieren weiterhin, sodass die meisten JSDoc-typisierten Codebasen unverändert übernommen werden können. TypeScript 7.0 ist seit Juli 2026 das Stable Release – man sollte das eigene Projekt dagegen testen, um die genauen Unterschiede zu sehen.