Jeder Beitrag über TypeScript 7 wird mit derselben Zahl aufmachen: zehnmal schneller. Interessanter ist die Tatsache, die in den Benchmarks untergeht. Der Compiler, der TypeScript prüft, ist nicht mehr in TypeScript geschrieben. Ein Blick darauf, warum das Team Go statt Rust gewählt hat, warum eine Portierung besser war als eine Neuentwicklung, was es bedeutet, dass Dogfooding verloren hat, und ob du jetzt schon wechseln solltest.
S
Sascha Becker
Author
8 Min. Lesezeit
TypeScript 7 ist nicht in TypeScript geschrieben
Jeder Ankündigungsbeitrag über TypeScript 7 wird mit derselben Zahl aufmachen. Zehnmal schneller. Das ist eine echte Zahl und sie ist es wert. Aber die interessantere Tatsache ist eine, die in den Benchmarks untergeht: Der Compiler, der TypeScript prüft, ist nicht mehr in TypeScript geschrieben.
Über ein Jahrzehnt lang lautete das Versprechen von TypeScript im Kern immer gleich. Typen machen große Codebasen überlebbar. Und der Compiler war der Beweis durch Beispiel. Er war eine der größten, meistgeforkten TypeScript-Codebasen überhaupt, und er war in genau der Sprache geschrieben, die er prüfte. Das war das Dogfood. Als das Team entschied, dass der Compiler eine Größenordnung schneller werden musste, kam es zu dem Schluss, dass der Weg dorthin bedeutete, die Sprache zu verlassen. TypeScript 7 ist eine Portierung dieses Compilers nach Go.
Das ist die Geschichte, die es zu erzählen lohnt. Nicht die Geschwindigkeit. Die Entscheidung, das eigene Essen nicht mehr selbst zu kochen, und was es aussagt, dass diese Entscheidung offensichtlich richtig war.
Was tatsächlich ausgeliefert wurde
Halten wir diesen Teil kurz, denn alle anderen werden ihn lang machen.
TypeScript 7 ist ein nativer Compiler. Dieselbe Sprache, dasselbe Typsystem, dieselbe Ausgabe, etwa der zehnfache Durchsatz. Die veröffentlichten Zahlen des Teams, an realen Projekten:
Typprüfungszeit auf drei großen Codebasen, jeweils normalisiert auf die eigene TypeScript-6-Basislinie. Zahlen aus der TypeScript-7.0-Ankündigung.
Der Speicherverbrauch sank über dieselben Projekte um sechs bis sechsundzwanzig Prozent. Im Editor, dem menschlicheren Maß, fiel das Auftauchen von Fehlern über die VS-Code-Codebasis von rund siebzehneinhalb Sekunden auf unter eineindrittel.1 Slack berichtete, die CI-Typprüfung von siebeneinhalb Minuten auf ein Viertel davon gesenkt zu haben. Der Language Server, also das, was tatsächlich darüber entscheidet, ob sich dein Editor lebendig anfühlt, meldet über achtzig Prozent weniger fehlgeschlagene Befehle und sechzig Prozent weniger Abstürze gegenüber der 6.0-Basislinie.
Nichts davon verlangte, dass du auch nur einen einzigen neuen Typ lernst. Das ist der ganze Punkt, und wir kommen darauf zurück.
Die Wahl von Go löste den erwartbaren Streit aus. Warum nicht Rust, die Sprache, die die Nische "schnelles Systemwerkzeug, geschrieben von Leuten, denen Korrektheit wichtig ist" besetzt? Die Antwort ist nicht Stammesdenken, und sie ist interessanter, als Stammesdenken es wäre.
Die internen Datenstrukturen des TypeScript-Compilers sind Graphen. Syntaxbäume, Symboltabellen und Typbeziehungen stecken voller zyklischer Referenzen: ein Knoten zeigt auf seinen Elternknoten, der Elternknoten zeigt zurück, Symbole referenzieren Typen, die Symbole referenzieren. Rusts Ownership-Modell ist per Design feindlich gegenüber genau dieser Form. Man kann zyklische Graphen in Rust bauen, aber man tut es mit Arenas, Integer-Indizes und Reference Counting, und wenn man damit fertig ist, hat man das Speichermodell des Type Checkers effektiv von Grund auf neu geschrieben. Das ist ein mehrjähriges Projekt mit eingebautem Risiko einer subtilen Verhaltensabweichung von dem Compiler, auf den sich Millionen von Menschen bereits verlassen.
Go geht den anderen Weg. Es hat Garbage Collection, es kommt mit zyklischen Referenzen zurecht, und Goroutines liefern günstige Shared-Memory-Parallelität über eine einzige Symboltabelle. Diese Kombination ermöglichte dem Team eine Portierung statt einer Neuentwicklung. Anders Hejlsberg beschrieb Go als die niedrigste Sprache, die sie erreichen konnten und die ihnen dennoch vollständige native Codeausgabe auf jeder Plattform, echte Kontrolle über das Daten-Layout und die Möglichkeit zyklischer Datenstrukturen gab.2 Rust, wie er es formulierte, gelingt bei seinen eigenen Zielen grandios, und "leicht, genau diese JavaScript-Codebasis dorthin zu portieren" war rational nie eines davon.
Das Wort Portierung leistet hier echte Arbeit. Die Go-Implementierung wurde, in der Beschreibung des Teams selbst, methodisch aus dem bestehenden Code portiert statt neu geschrieben, und ihre Typprüfungslogik ist strukturell identisch mit TypeScript 6.0.1 Deshalb landete sie in etwa einem Jahr statt nie, und deshalb kannst du darauf vertrauen, dass sie deinen Code genauso typisiert wie der alte Compiler. Die eine Stelle, an der improvisiert werden musste, war das File Watching, wo Gos Standardbibliothek zu kurz griff, also portierten sie Parcels C++-Watcher nach Go mit ein paar Assembly-Shims, statt eine neue native Abhängigkeit aufzunehmen. Selbst die Notausfahrt war eine Portierung.
Die Häresie, näher betrachtet
Hier ist das, was dich nicht loslassen sollte. Die stärkste denkbare Werbung für eine Sprache ist, dass ihr eigenes Tooling in ihr geschrieben ist und gedeiht. TypeScript hatte das. Es gab es bewusst auf.
Man kann das auf zwei Arten lesen, und beide sind zugleich wahr.
Die unbequeme Lesart ist, dass Self-Hosting immer teils Theater war. Ein Compiler ist ein Batch-Programm, das riesige Graphen alloziert, dieselben heißen Schleifen milliardenfach durchläuft und sich dann beendet. Das ist eine Last, mit der Managed Languages schlicht schlechter umgehen als native, und keine Markentreue ändert etwas an der Physik. In dem Moment, in dem Performance zur Priorität über dem Prinzip wurde, verlor das Prinzip, und zwar deutlich.
Die großzügige Lesart ist, dass genau so Reife aussieht. Dogfooding ist ein Mittel, kein Zweck. Seine Aufgabe ist es, die Leute, die ein Werkzeug bauen, ehrlich darüber zu halten, wie sich das Werkzeug benutzen lässt. TypeScript hat jetzt hunderttausend echte Codebasen, die diese Aufgabe erfüllen. Es braucht seinen Compiler nicht als eine davon. Die Sprache um den Preis der Build-Zeit jedes Nutzers rein zu halten, wäre die eitle Wahl gewesen, nicht die tugendhafte.
Was ich wirklich klärend finde, ist, dass die pragmatische und die ideologische Wahl in entgegengesetzte Richtungen zeigten, und das Team wählte den Pragmatismus ohne sichtbare Qual. Go statt Rust, weil es zum bestehenden Code passte. Nativ statt Managed, weil die Last es verlangte. Portierung statt Neuentwicklung, weil Nutzer identische Semantik dringender brauchten als ein frisches Design. Jede dieser Antworten ist die langweilige, richtige, nicht tweetbare, und alle drei auf einmal auszuliefern ist die eigentliche Leistung.
Solltest du tatsächlich wechseln
Nun die praktische Hälfte, denn "es ist schneller" ist nicht dasselbe wie "am Montag umstellen."
7.0 und 6.0 sind auf Koexistenz ausgelegt. 7.0 übernimmt die Defaults von 6.0 und verwandelt alles, was 6.0 als veraltet markiert hat, in einen harten Fehler, sodass der Migrationspfad zuerst durch 6.0 führt. Es gibt ein Kompatibilitätspaket, @typescript/typescript6, das den alten Compiler als tsc6 neben dem neuen installiert, sodass du ein Monorepo Paket für Paket umziehen kannst statt in einem einzigen Sprung.
Auch die Defaults haben sich verschoben. strict ist jetzt ab Werk true, module ist standardmäßig esnext, rootDir ist standardmäßig ./, und types ist standardmäßig eine leere Liste, sodass globale Typpakete explizit benannt werden müssen. Die bruchgefährdeten Kanten lohnen sich zu lesen, bevor du im Zorn upgradest. Eine Auswahl dessen, was jetzt hart fehlschlägt statt still zu warnen:
jsonc
// TypeScript 7 lehnt diese rundheraus ab. Alle wurden zuerst in 6.0 als veraltet markiert.
"target": "es5", // weg; kein ES5-Downlevel mehr
"downlevelIteration": true, // weg
"moduleResolution": "node", // nutze "bundler" oder "nodenext"
"esModuleInterop": false, // lässt sich nicht mehr abschalten
"module": "amd" | "umd" | "system", // weg
Und die Einschränkung, die die meisten Teams tatsächlich ausbremsen wird: das Tooling für eingebettete Sprachen ist noch nicht bereit. Vue, Svelte, Astro, Angular und MDX hängen alle an einer programmatischen Compiler-API, die der Native Port noch nicht bereitstellt. Diese API ist für 7.1 vorgesehen. Wenn dir die Editor-Erfahrung für .vue- oder .svelte-Dateien wichtig ist, und das ist sie, dann wartest du.
Das ehrliche Fazit
Die Kommandozeilen- und CI-Geschichte ist heute bereit: richte den nativen
Compiler auf deinen Build, spüre die Beschleunigung, und behalte tsc6 für
alles, was bricht. Die Editor-Geschichte für Framework-Single-File-Components
wartet auf 7.1. Ziehe deinen Typprüfungs-Job in der CI jetzt um. Halte die
Editoren deines Teams zurück, bis das Tooling, von dem du abhängst, gegen die
neue API ausgeliefert wird.
Es gibt eine Überholspur für die Ungeduldigen. Das neue Flag --checkers steuert, wie viele Typprüfungs-Worker parallel laufen, standardmäßig vier. Das Team maß eine 16,7-fache Beschleunigung auf VS Code, indem es auf acht erhöhte. --builders tut dasselbe für Projektreferenzen in einem Monorepo, und --singleThreaded schaltet alles ab, wenn du ein deterministisches Profil brauchst. Das sind die Stellschrauben, die aus "zehnmal schneller" ein "so schnell, wie diese Maschine es erlaubt" machen.
Bis das Werkzeug verschwindet
Das Ehrlichste an TypeScript 7 ist, wie wenig es von dir verlangt. Keine neue Syntax. Keine neuen Typen. Nichts umzulernen. Der gesamte Release ist dieselbe Sprache, die schneller ankommt. Das lässt sich leicht mit einem langweiligen Release verwechseln, und es ist genau andersherum. Die Upgrades, die verändern, wie sich die Arbeit anfühlt, ohne zu verändern, was du wissen musst, sind die seltenste und wertvollste Art. Du bemerkst TypeScript 7 so, wie du bemerkst, dass eine Straße neu asphaltiert wurde: nicht, während du sie fährst, nur in der Abwesenheit des Schlaglochs, das du zu sehen aufgehört hattest.
Und der Preis dafür war eine leise Häresie. Eine Sprache, die sich damit verkaufte, Typen zu vertrauen, um große Systeme zu zähmen, sah ihr eigenes großes System an und entschied, dass der ehrliche Zug war, es in etwas anderem zu bauen. Das ist kein Verrat an der Idee. Es ist die Idee, erwachsen genug geworden, um sich nicht länger am eigenen Compiler beweisen zu müssen.
