TypeScript 7 im JavaScript-Ökosystem

TypeScript 7 im JavaScript-Ökosystem

0:00 TypeScript 7 ist im Juli 2026 erschienen, und seitdem kursiert eine Zahl durch die Entwicklerwelt: zehnmal schneller. Das klingt nach Sensation, und genau deshalb lohnt sich der nüchterne Blick. Denn was sich geändert hat, ist nicht die Sprache — es ist der Motor darunter. Wer das früh versteht, spart sich einen ganzen Tag voller Fragen nach neuen Sprachfeatures, die es schlicht nicht gibt.

0:22 In diesem ersten Modul legen wir das Fundament: Wo hört JavaScript auf, wo fängt TypeScript an, was passiert beim Übersetzen, und was bedeutet der neue Compiler wirklich für Ihren Arbeitsalltag.

TypeScript 7 im JavaScript-Ökosystem

0:34 Ein Satz zieht sich durch diesen ganzen Tag: Ein Typ ist eine Aussage über den Code, keine Zusicherung über die Daten. Klingt spitzfindig, ist aber der Unterschied zwischen einer Anwendung, die im Betrieb hält, und einer, die genau dort bricht, wo Daten von außen hereinkommen. Wir arbeiten uns von der Begriffsklärung über das Verhalten beim Übersetzen bis zum Projektaufbau vor und stellen am Ende gemeinsam ein bestehendes JavaScript-Modul um.

0:59 Danach ist klar, wofür TypeScript zuständig ist — und wofür eben nicht.

TypeScript, JavaScript und ECMAScript

1:03 Fangen wir mit drei Begriffen an, die im Alltag ständig durcheinandergeraten. Das wirkt auf den ersten Blick akademisch, erspart Ihnen aber später jede zweite Rückfrage. Denn fast jedes Problem, das im Projekt auftaucht, lässt sich einer dieser drei Ebenen zuordnen — und damit ist meistens schon klar, wo die Lösung zu suchen ist.

1:23 Stellen Sie sich eine Bauordnung, ein fertiges Haus und den Bauplan vor. ECMAScript ist die Bauordnung: der Standard, der festlegt, was die Sprache können muss. JavaScript ist das Haus, das dieser Ordnung folgt und tatsächlich bewohnt wird. Und TypeScript ist der Bauplan mit allen Maßangaben — er hilft beim Bauen enorm, aber niemand wohnt darin. Jede gültige JavaScript-Datei ist zugleich gültiges TypeScript.

1:47 Und alles, was TypeScript hinzufügt, verschwindet beim Übersetzen wieder. Das ist der entscheidende Punkt: TypeScript verleiht der Sprache keine einzige neue Fähigkeit zur Laufzeit. Es hilft Ihnen, den richtigen Code zu schreiben — mehr nicht, und das ist schon eine Menge. Interessant an dieser Aufstellung ist nicht, wer was festlegt, sondern wer es durchsetzt. Beim Standard ist es ein Gremium — das dauert Jahre und ist politisch.

2:13 Bei JavaScript ist es die Engine im Browser oder in Node: Sie entscheidet gnadenlos und im Moment der Ausführung. Und bei TypeScript ist es der Compiler, also eine Instanz, die lange vor der Auslieferung arbeitet und danach gar nicht mehr da ist. Wenn Sie sich bei einem Problem fragen, wer hier eigentlich Recht spricht, haben Sie die Antwort meist schon gefunden.

2:33 Diese Spalte ganz rechts ist die praktisch nützlichste der ganzen Folie. Jetzt wird die Theorie handfest. Ein Sprachfeature fehlt? Dann ist das eine Frage an das Übersetzungsziel, nicht an TypeScript. Ein Fehler tritt erst im Betrieb auf? Dann war es nie eine Frage an den Compiler — der hätte ihn gar nicht sehen können. Eine Bibliothek bringt keine Typen mit?

2:56 Ein reines TypeScript-Problem, JavaScript stört das nicht. Und wenn Ihr Editor grün leuchtet, der Browser aber rot, dann passen Zielversion und tatsächliche Laufzeitumgebung nicht zusammen. Vier typische Situationen, vier klare Zuständigkeiten. Das spart im Projekt erstaunlich viel Suchzeit. Drei Missverständnisse begegnen einem immer wieder. Das erste: TypeScript für eine eigene Sprache zu halten und das eigene JavaScript-Wissen abzuwerten.

3:24 Das Gegenteil stimmt — Ihr JavaScript-Wissen ist hier fast alles wert. Das zweite: zu erwarten, dass der Compiler das Laufzeitverhalten verändert oder absichert. Er tut beides nicht. Und das dritte, gerade jetzt besonders aktuell: Sprachstand und Compilerstand zu verwechseln. TypeScript 7 bringt kein neues ECMAScript mit.

3:44 Wer nach der Umstellung nach neuen Sprachfeatures sucht, sucht am falschen Ort. Behalten Sie das im Kopf, wenn wir gleich über die neue Version sprechen.

Compile-Time-Typen und Type Erasure

3:54 Jetzt kommt das Kapitel, auf das im ganzen Seminar am häufigsten zurückverwiesen wird. Es geht um die Frage, was von Ihren sorgfältig geschriebenen Typen eigentlich übrig bleibt, wenn der Code beim Kunden läuft. Die Antwort ist unbequem und macht genau deshalb den Unterschied zwischen einem soliden und einem naiven Umgang mit TypeScript aus.

4:13 Typen existieren nur bis zum Übersetzungszeitpunkt. Danach bleibt reines JavaScript übrig, dem jede Typinformation fehlt. Der Fachbegriff dafür ist Type Erasure — Typlöschung. Das Bild dazu: Denken Sie an eine Schablone, mit der Sie eine Wand streichen. Solange Sie arbeiten, hält die Schablone alles an Ort und Stelle. Ist die Farbe trocken, nehmen Sie sie ab — und die Wand weiß nichts mehr davon. Wichtig: Das ist keine Unfertigkeit der Umsetzung, die irgendwann behoben wird.

4:43 Es ist eine bewusste Entscheidung des Sprachentwurfs. TypeScript wollte nie die Laufzeit anfassen, und genau deshalb ist es überhaupt so verbreitet. Sehen Sie sich die beiden Fassungen nebeneinander an. Oben eine Funktion, die Auftragsbeträge aufsummiert, mit einer sauber beschriebenen Struktur und einer klaren Signatur.

5:03 Unten dieselbe Funktion nach dem Übersetzen — und das Aufschlussreiche ist, was fehlt. Die Beschreibung der Struktur ist restlos verschwunden, die Signatur auch. Die Rechnung selbst ist Zeichen für Zeichen dieselbe geblieben. Was heißt das praktisch? Nichts in diesem Ergebnis prüft noch, ob der Betrag wirklich eine Zahl ist.

5:23 Kommt dort ein Text an, rechnet JavaScript munter weiter und liefert Unsinn. Der Compiler hat sein Bestes gegeben — er ist nur zur Laufzeit nicht mehr dabei. Ziehen wir die Konsequenz. Ein Typ beschreibt eine Absicht, er erzwingt zur Laufzeit nichts. Überall dort, wo Daten von außen kommen, ist ein Typ deshalb nicht mehr als eine Behauptung — geprüft werden muss getrennt davon.

5:46 Und kein Typ überlebt die Netzwerkgrenze, den Dateizugriff oder das Formular. Genau an dieser Naht sitzen in der Praxis die teuren Fehler: nicht in der Geschäftslogik, sondern dort, wo Fremdes hereinkommt und ungeprüft für vertrauenswürdig gehalten wird. Merken Sie sich diese Naht. Modul 6 handelt von nichts anderem, und in Modul 13 werden wir sehen, dass auch generierter Code sie gern übersieht.

6:10 Diese drei Fehler haben eine gemeinsame Wurzel: den Wunsch, der Compiler möge mehr können, als er kann. Zu erwarten, dass eine Annotation die Antwort einer Schnittstelle validiert — tut sie nicht. Mit einer Type Assertion einen Fehler wegzudrücken, statt die Daten zu prüfen — das ist, als würden Sie die Warnleuchte im Auto überkleben.

6:29 Und Typen als Sicherheitsgrenze einzusetzen — sie sind keine Zugriffskontrolle, weil zur Laufzeit schlicht nichts von ihnen übrig ist. Der dritte Punkt ist der gefährlichste, weil er im Code so überzeugend aussieht.

Vier Einsatzorte, vier Anforderungen

6:42 Bis hierher haben wir über TypeScript gesprochen, als gäbe es nur eine Art, es einzusetzen. Das stimmt nicht. Dieselbe Sprache stellt an vier typischen Orten deutlich verschiedene Ansprüche an Strenge und Sorgfalt — und wer das nicht trennt, konfiguriert eine Bibliothek wie eine Anwendung. Oder umgekehrt. Lesen Sie diese Tabelle von rechts nach links, also über die Spalte „Was schiefgeht" — dort steckt die eigentliche Aussage.

7:07 Im Frontend nimmt man Formulareingaben als geprüft an, obwohl sie aus dem Browser kommen und alles sein können. Im Backend vertraut man den Antworten fremder Dienste. In der geteilten Domäne sickern Infrastrukturdetails ins Modell, weil beide Seiten dasselbe benutzen. Und bei einer Bibliothek werden interne Typen versehentlich öffentlich und lassen sich danach kaum noch ändern. Vier Orte, vier ganz eigene Arten, sich selbst ein Bein zu stellen.

7:33 Die Muster wiederholen sich erstaunlich zuverlässig. Der wichtigste Satz hier ist der zweite: Veröffentlichte Typen sind eine Zusage über Jahre, kein Implementierungsdetail. Eine Anwendung dürfen Sie pragmatisch konfigurieren — wird es unbequem, ändern Sie es morgen. Eine Bibliothek nicht, denn dort hängen fremde Projekte an Ihren Signaturen.

7:54 Geteilte Modelle wiederum brauchen vor allem eine klare Regel, wem sie eigentlich gehören; ohne die verwahrlosen sie zuverlässig. Und all das schlägt sich ganz konkret nieder: Die Konfigurationsdatei sieht in jedem der vier Fälle anders aus. Wir kommen in Kapitel 6 darauf zurück.

Von TypeScript 5.x über 6.0 zu 7.0

8:11 Jetzt zur Versionsgeschichte — und die ist ausnahmsweise wirklich wichtig, weil sie Ihre Migrationsplanung bestimmt. Zwischen der alten Welt und dem neuen Compiler liegt eine Zwischenstation, und wer sie überspringt, bezahlt dafür später. In einem Satz: Sechs räumt auf, sieben tauscht den Motor. Diese drei Zeilen erzählen eine Geschichte mit klarer Rollenverteilung.

8:33 Die Fünfer-Reihe ist der letzte Stand der alten Welt: nachsichtige Voreinstellungen, Altoptionen noch vorhanden. Version 6.0 ist der Aufräumer — sie hat die Voreinstellungen umgestellt, damit strenge Prüfung und moderne Module ab Werk gelten, und sie hat markiert, was nicht mehr erwünscht ist. Und 7.0 zieht die Konsequenz: entfernt, was 6.0 nur angemahnt hat, und bringt den neuen Compiler mit.

8:57 Der Hinweis unten ist ernst gemeint — alle Zahlen und Optionen dieses Moduls sind in unserem Quellendossier mit Datum belegt. Bei diesem Thema kursiert viel Halbwissen. Die Planungsaussage steht gleich in der ersten Zeile: Was 6.0 als Warnung meldet, weist 7.0 als Fehler ab. Damit haben Sie eine Arbeitsliste, die Sie sich nicht ausdenken müssen — der Compiler schreibt sie Ihnen.

9:20 Wer dagegen von 5.x direkt auf 7.0 springt, bündelt zwei Umstellungen zu einer und weiß bei jedem Fehler nicht, welche der beiden ihn verursacht hat. Das ist der Grund für unsere Reihenfolge im Seminar: erst aufräumen, dann den Motor tauschen. In Modul 9 gehen wir diesen Weg vollständig durch, mit beiden Compilern parallel im selben Projekt.

9:42 Der erste Punkt ist der beliebteste Selbstbetrug der Branche: eine Option setzen, die veraltete Einstellungen weiter durchgehen lässt, und die Arbeit für erledigt halten. Sie ist nicht erledigt, sie ist vertagt — und zwar auf den Tag, an dem 7.0 sie hart abweist. Der zweite: auf 7.0 gehen, ohne die Warnungen aus 6.0 überhaupt gelesen zu haben.

10:03 Und der dritte betrifft die Recherche: In Artikeln aus 2025 heißt der neue Compiler noch mit seinem Vorschaunamen. Dieser Name ist Geschichte. Wer ihn heute noch liest, liest einen veralteten Text — ein brauchbarer Frischetest für jede Quelle.

TypeScript 7 als nativer Compiler

10:19 Kommen wir zu der Zahl, wegen der viele überhaupt hier sitzen. TypeScript 7 ist deutlich schneller, und zwar nachweislich. Wir sehen uns an, woher das kommt, was gemessen wurde — und ebenso wichtig: was diese Messungen über Ihr Projekt gerade nicht aussagen. Bisher war der TypeScript-Compiler selbst ein JavaScript-Programm, das in Node lief.

10:40 Sinnbildlich: ein Übersetzer, der beim Arbeiten in derselben Sprache denken musste, die er übersetzt. Version 7.0 ist eine Neuimplementierung in Go, nativ übersetzt und mit paralleler Typprüfung — der Übersetzer ist jetzt ein Fachmann mit eigenem Werkzeug und mehreren Händen. Für Sie ändert sich am Code nichts: Sprache, Syntax und Typregeln bleiben unverändert. Sie installieren weiterhin dasselbe Paket und rufen weiterhin denselben Befehl auf.

11:07 Nur eben schneller. Das ist die ganze Neuerung, und sie ist bemerkenswert unspektakulär in ihrer Wirkung auf Ihren Quelltext. Drei sehr große Open-Source-Projekte, jeweils mit beiden Compilerversionen vollständig gebaut. Die Faktoren liegen zwischen knapp neun und knapp zwölf, dazu sinkt der Speicherbedarf. Bemerkenswert ist weniger die Höhe der Zahlen als ihre Streuung: Selbst unter kontrollierten Bedingungen schwankt der Gewinn deutlich.

11:33 Das liegt daran, wie groß der Anteil der Typprüfung an der gesamten Bauzeit ist — und der ist von Projekt zu Projekt verschieden. Nehmen Sie diese Zeilen also als Hausnummer, nicht als Zusage. Was für Ihr Projekt gilt, wissen Sie erst, wenn Sie es selbst gemessen haben. Genau darum geht es in Modul 10. Interessanter als die Faktoren ist, was sie mit dem Arbeitsverhalten machen.

11:56 Wenn ein vollständiger Build von Minuten auf Sekunden fällt, wird Rückmeldung billig — und was billig ist, holt man sich öfter. Wenn der Editor an einer großen Datei in Sekundenbruchteilen antwortet statt in gefühlten Ewigkeiten, verliert man den Gedanken nicht mehr. Kurze Prüfzeiten machen häufiges Prüfen überhaupt erst zumutbar.

12:14 Und für Coding Agents, die wir ab Modul 11 behandeln, ist das kein Komfort, sondern schlicht Voraussetzung: Ein Agent, der nach jeder Änderung prüft, braucht eine Prüfung, die Sekunden dauert, nicht Minuten. Der mittlere Punkt ist der praktisch wichtigste des ganzen Kapitels: Version 7.0 bringt keine Compiler-Schnittstelle mit — die kommt erst mit 7.1.

12:35 Alles, was programmatisch auf den Compiler zugreift, kann also noch nicht mit. Und das ist mehr, als man zunächst denkt: Vue, Svelte, Astro, MDX und Angular-Templates werden ausdrücklich als noch nicht bereit genannt. Wenn Sie einen Migrationstermin planen, prüfen Sie deshalb zuerst Ihre Werkzeugkette, nicht Ihren Code. Und lesen Sie die Beschleunigungsfaktoren als das, was sie sind: Messungen an fremden Projekten.

Projektaufbau und Konfiguration

13:01 Genug Einordnung — jetzt legen wir ein Projekt an. Es sind im Kern drei Dateien, die über alles Weitere entscheiden, und die Konfigurationsdatei ist davon die einflussreichste. Interessant an ihr ist heute vor allem, wie wenig darin stehen sollte. Sehen Sie sich an, was hier steht — und vor allem, was nicht. Es fehlen die strenge Prüfung und die Zielversion, und zwar mit Absicht: Seit Version 6.0 sind beide voreingestellt.

13:27 Wer sie trotzdem hinschreibt, erzeugt Rauschen. Der Grundsatz lautet: Diese Datei enthält Entscheidungen, keine Bestätigungen. Was tatsächlich dort steht, ist jeweils eine bewusste Wahl — die Modulauflösung für Node, die Node-Typen, die Trennung von Quell- und Ausgabeverzeichnis und die Deklarationen für Konsumenten. Sieben Zeilen, die man in einem Atemzug liest. Vergleichen Sie das einmal mit der Konfiguration in Ihrem eigenen Projekt.

13:54 Der rote Faden dieser fünf Schritte ist: Erst die Regeln, dann der Code. Zunächst die Projektdatei mit der Festlegung auf moderne Module, dann der Compiler als Entwicklungsabhängigkeit. Anschließend die Konfiguration — und nur das, was vom Standard abweicht. Dann die Skripte, damit Prüfung und Build einen Namen haben. Und erst ganz zum Schluss die erste Quelldatei.

14:16 Die Reihenfolge ist kein Formalismus: Wer vor der Konfiguration Code schreibt, konfiguriert später gegen bestehende Fehler und wird dann jede strenge Einstellung als Zumutung empfinden. Am leeren Projekt kostet Strenge nichts. Der erste Punkt ist der häufigste und wird selten als Fehler erkannt: Optionen abschreiben, die längst Voreinstellung sind.

14:36 Die Datei wird dadurch nicht falsch, aber unlesbar — und niemand sieht mehr, was eigentlich entschieden wurde. Die anderen beiden sind Klassiker mit sofortiger Wirkung: Fehlen die Node-Typen, kennt der Compiler die Node-Globals nicht und meldet Selbstverständliches als unbekannt. Und wer das Quellverzeichnis nicht angibt, bekommt eine verschachtelte Ausgabestruktur, die beim Veröffentlichen alle Pfade verschiebt.

tsc als Type Checker, Compiler und Generator

15:00 Der Compiler-Befehl heißt schlicht tsc, und die meisten benutzen ihn, ohne zu bemerken, dass er drei völlig verschiedene Aufgaben erledigt. Diese Aufgaben zu trennen, ist eine der lohnendsten kleinen Umstellungen überhaupt — und sie wird spätestens dann wichtig, wenn ein anderes Werkzeug das Übersetzen übernimmt. Die spannende Spalte ist wieder die rechte. Das Prüfen der Typen übernimmt fast immer der Compiler selbst — dafür gibt es kaum Alternativen und keinen Grund, eine zu suchen.

15:27 Das Erzeugen von JavaScript dagegen übernimmt heute in vielen Projekten ein Bundler, weil er ohnehin bündelt und dabei deutlich schneller ist. Und die Deklarationen, also die mitgelieferten Typbeschreibungen, macht wieder der Compiler — sie brauchen Sie, sobald andere Ihr Paket verwenden. Wichtig ist die Schlussfolgerung: Wenn Sie das Übersetzen abgeben, müssen Sie das Prüfen ausdrücklich behalten. Sonst fällt es lautlos weg.

15:52 Aus dieser Trennung werden drei kurze Skripte, und das mittlere Wort im ersten davon ist das entscheidende: nur prüfen, nichts erzeugen. Genau dieser Aufruf ist der, den Sie in Ihre Pipeline hängen — und den ein Coding Agent später selbstständig ausführen kann, um seine eigene Arbeit zu kontrollieren. Deshalb lohnt es sich, ihm einen eigenen Namen zu geben, statt ihn im Build zu verstecken. Was keinen Namen hat, kann niemand einzeln aufrufen, weder Mensch noch Maschine.

16:19 Drei Zeilen Konfiguration, die den Unterschied zwischen gelegentlicher und verlässlicher Prüfung ausmachen. Der erste Fehler passiert lautlos: übersetzen, ohne zu prüfen, und die Trennung gar nicht bemerken. Der Build ist grün, der Fehler unterwegs. Der zweite trifft andere: Wer eine Bibliothek ohne Deklarationen ausliefert, entwertet sie für alle Konsumenten — sie sehen dann nur noch eine namenlose Blackbox.

16:44 Und der dritte ist der subtilste: die Typprüfung nur im Editor laufen zu lassen. Der Editor prüft, was gerade offen ist. Die Pipeline prüft alles. Solange nur der Editor prüft, entscheidet der Zufall darüber, was auffällt.

Übung — ein Projekt umstellen

16:59 Jetzt sind Sie dran. Wir nehmen ein bestehendes JavaScript-Modul und stellen es schrittweise um. Der eigentliche Gewinn dieser Übung ist nicht die fertige Umstellung — es ist die Erfahrung, dass der Compiler beim ersten Durchlauf Dinge findet, die beim Lesen des Codes jahrelang durchgegangen sind. Das Lernziel ist bewusst eng gefasst: eine bestehende Codebasis schrittweise typisieren, ohne ihr Verhalten zu verändern.

17:22 Diese Zurückhaltung ist die eigentliche Übung — die Versuchung, unterwegs auch noch aufzuräumen, ist groß und macht jede Migration unnachvollziehbar. Erfolgreich sind Sie, wenn die Typprüfung fehlerfrei durchläuft, das Modul sich unverändert verhält und Sie mindestens einen zuvor unbemerkten Defekt benennen können. Wer früh fertig wird, schaltet die Deklarationen ein und schaut nach, welche internen Typen dabei ungewollt öffentlich werden — meist eine kleine Überraschung.

17:49 Der Ablauf hat eine kleine Pointe eingebaut. Sie beginnen damit, das Projekt zu lesen und zu notieren, welche Stellen Ihnen typkritisch vorkommen — das ist Ihre Vermutung. Dann richten Sie die Konfiguration ein, benennen die Dateien um und arbeiten die Fehler von außen nach innen ab, ohne Verhalten zu ändern. Jeden Befund, der Ihnen beim Lesen nicht aufgefallen ist, halten Sie fest. Und ganz am Ende vergleichen Sie Ihre Liste von vorhin mit dem, was der Compiler gefunden hat.

18:18 Diese Gegenüberstellung ist der Kern der Übung. Und noch eine Regel: keine Type Assertions. Wer eine bräuchte, notiert die Stelle — das ist Material für Modul 2. Vier Sätze zum Mitnehmen. Typen sind Aussagen über den Code und verschwinden beim Übersetzen — das ist die Grundlage für alles, was folgt. TypeScript 6 räumt auf, TypeScript 7 tauscht den Compiler, nicht die Sprache. Die Beschleunigung ist real und gemessen, aber kein Versprechen für Ihr Projekt.

18:45 Und weil 7.0 noch keine Compiler-Schnittstelle mitbringt, hängt Ihr Migrationstermin an den Werkzeugen, nicht am eigenen Code. Im nächsten Modul gehen wir eine Ebene tiefer und sehen uns an, wie viel der Compiler von allein weiß — und wo Sie ihm nachhelfen müssen.