TypeScript

Zwei Angaben liegen vor, und sie widersprechen sich um den Faktor zweieinhalb. Gao, Bird und Barr annotierten für die begutachtete ICSE-Studie 2017 fehlerhafte JavaScript-Änderungen nachträglich und fanden, dass TypeScript rund 15 Prozent der Fehler gemeldet hätte. Airbnb nannte in einem Konferenzvortrag 38 Prozent aus sechs Monaten eigener Störungsberichte – eine Selbstauskunft, keine begutachtete Messung. Beide Zahlen haben dieselbe Kehrseite: Die Mehrheit der Fehler bleibt unentdeckt.

Der strict-Modus ist kein einzelner Schalter, sondern eine Sammeloption: Die amtliche Konfigurationsreferenz führt neun Einzelflags in der strict-Familie, darunter noImplicitAny, strictNullChecks und strictPropertyInitialization. Ohne strictNullChecks gehören null und undefined zu jedem Typ – die Prüfung fällt dort weitgehend aus. Die Dokumentation warnt zugleich, dass künftige Versionen unter demselben Flag weitere Prüfungen aufnehmen können. Ein Versionssprung kann deshalb neue Fehler melden, ohne dass sich eine Zeile Code geändert hat.

Nicht die strengste Einstellung am ersten Tag setzen. Bei einem gewachsenen Projekt meldet der Compiler dann auf einen Schlag hunderte Fehler, die sich keinem einzelnen Arbeitsschritt mehr zuordnen lassen. Tragfähiger ist die Reihenfolge: erst den Mischbetrieb erlauben, damit alte und neue Dateien nebeneinander laufen, dann implizite Typen verbieten, jeden Fehler beheben, sichern – und die Null-Prüfung zuletzt, weil dieses Flag den meisten Code berührt. Jede Stufe bleibt einzeln prüfbar und einzeln umkehrbar.

Nichts – die Typen sind vorher verschwunden. Der Compiler entfernt Annotationen, Schnittstellen und Typaliase beim Übersetzen; im ausgelieferten JavaScript steht keine Zeile davon. Die erklärten Entwurfsziele führen das ausdrücklich als Nichtziel: keine Typinformation zur Laufzeit und kein abweichender Code aufgrund der Typprüfung. Praktisch heißt das zweierlei: Eine Schnittstelle lässt sich zur Laufzeit nicht abfragen, und die ausgelieferte Datei wird durch noch so viele Typen kein Byte größer.

Der Typ any hebt die Prüfung für diesen Wert auf, und zwar auch für alles, was daraus abgeleitet wird – der Compiler schweigt ab dieser Stelle. Das Flag noImplicitAny aus der strict-Familie greift nur bei den stillen Fällen, nicht bei einem hingeschriebenen any. Wer einen Wert wirklich nicht kennt, nimmt unknown: Damit erzwingt TypeScript eine Prüfung, bevor der Wert benutzt werden darf. Aus demselben Grund setzt useUnknownInCatchVariables Fehlerobjekte auf unknown.

Microsoft hat den Compiler nach Go portiert und die Messwerte im März 2025 veröffentlicht: Das Projekt hinter Visual Studio Code mit 1.505.000 Zeilen brauchte mit dem bisherigen Compiler 77,8 Sekunden, mit dem nativen 7,5 – Faktor 10,4. Die Ladezeit des Projekts im Editor fiel von 9,6 auf 1,2 Sekunden. Der Punkt bleibt derselbe: TypeScript prüft in einem eigenen Schritt, den reines JavaScript gar nicht kennt.