Im CI-Log stand 77.8s für den Typecheck, und im Team hat längst niemand mehr hochgeschaut. Die Zahl stammt von den 1.5 Millionen Zeilen in VS Code unter dem alten JavaScript-Compiler, und mit TypeScript 7.0, der nativen Portierung, die Microsoft im März 2025 als Project Corsa begonnen hat, ist derselbe Job nach 7.5s fertig. Ich habe ein Dutzend Hot Takes darüber gelesen, warum sich das Team für Go statt Rust entschieden hat. Meine Position geht ein bisschen gegen den Strich: Die Sprachdebatte ist das Uninteressanteste an diesem Release, und was PHP-Entwickler studieren sollten, ist das Kleingedruckte darüber, was nicht mitgeliefert wurde.

Erst mal das Lob, denn es ist verdient. Die Begründung für Go war erfrischend unspektakulär. Das Team wollte eine Portierung, die sich exakt wie der alte Compiler verhält, Eigenheiten inklusive, also wurde der bestehende Code Datei für Datei übersetzt statt neu entworfen. Ein Compiler ist ein Dickicht aus Knoten, die Zeiger auf Eltern, Kinder und Deklarationen halten, und eine Sprache mit Garbage Collection und schlichten Zeigern lässt diesen Graphen den Umzug unbeschadet überstehen. Dazu kommt Parallelität über gemeinsamen Speicher beim Parsen und Prüfen, die ein einzelner Node-Thread nie geboten hat, und schon landest du bei den berichteten 8x bis 12x auf großen Projekten. TypeORM kam auf 13.5x. date-fns mit 104K Zeilen auf 9.5x. Das sind echte Stunden, die echten Menschen zurückgegeben werden.

Jetzt zum Kleingedruckten. TypeScript 7.0 hat keine stabile programmatische API; die ist für 7.1 vorgesehen. Bis dahin bleibt alles, was direkt mit dem Compiler spricht, auf TypeScript 6, und auf dieser Liste stehen typescript-eslint sowie das Template-Tooling für Vue, Svelte, Astro, MDX und Angular. Außerdem sind Deprecations jetzt harte Fehler, und der Strict Mode ist standardmäßig aktiv. Ein großer Teil des Ökosystems schaut dem Geschwindigkeitsgewinn also von der anderen Seite der Scheibe aus zu.

An dieser Stelle denke ich an unser eigenes Haus. Statische Analyse für PHP ist in PHP geschrieben, und ihr Wert lag nie allein in der Kern-Engine. Er liegt in der Erweiterungsschicht: in den Framework-bewussten Plugins, die einem Analyser beibringen, was eine Facade zurückgibt, was eine Repository-Methode hydriert und welche magische Property tatsächlich existiert. Die Hälfte der PHP-Shops, die ich kenne, würde ohne diese Plugins überhaupt keine statische Analyse fahren, weil die rohen Befunde auf einer Framework-Codebasis größtenteils Rauschen sind. Jedes Mal, wenn jemand eine native Neuschreibung unserer Analyser ins Spiel bringt, und irgendwer tut das immer, bekommt die Benchmark-Folie den Applaus, während in Wahrheit die Plugin-API darüber entscheidet, ob überhaupt jemand umsteigen kann.

Das stärkste Gegenargument verdient ein faires Gehör. Tempo verändert Verhalten. Wenn eine vollständige Analyse neunzig Sekunden dauert, lassen die Leute sie in der CI laufen und nirgends sonst; dauert sie neun, lassen sie sie beim Speichern laufen, und die gefundenen Bugs wandern vom Pull Request in den Editor, was mehr wert ist als jedes Plugin. Man könnte argumentieren, Microsoft habe richtig entschieden, zuerst den schnellen Kern auszuliefern und die Integrationen nachziehen zu lassen, denn auf alles zu warten hätte den Gewinn für die Mehrheit verzögert, die einfach nur tsc ausführt. Für TypeScript halte ich das für richtig, bei Microsofts Personaldecke und mit einem 7.1, das schon im Kalender steht. Viel weniger sicher bin ich, ob sich das auf ein Ökosystem wie unseres übertragen lässt, in dem die Analyser von einer Handvoll Leuten gepflegt werden und die Plugins von einer verstreuten Schar Freiwilliger, die eine inkompatible API nach fremdem Zeitplan nicht einfach wegstecken können.

Wenn ich also einen PHP-Tool-Autor beraten müsste, der mit dem nativen Weg liebäugelt, würde ich die TypeScript-Reihenfolge umdrehen. Zuerst den Erweiterungsvertrag definieren und einfrieren, und zwar in der aktuellen Implementierung, und erst danach die Engine darunter austauschen. Der Ansatz der originalgetreuen Portierung, den das TypeScript-Team gewählt hat, spricht sogar dafür: Wenn der neue Code die alte Struktur Zeile für Zeile spiegelt, kann auch die Grenze, an der Plugins andocken, gespiegelt werden. Und vergiss nicht, wie viel PHP selbst uns schon geschenkt hat. Vieles, wofür man früher die Sprache verlassen musste, kommt heute daher, dass die Engine schneller wird und Arbeit in parallelen Prozessen läuft, was unsere Analyser längst tun.

Nichts davon schmälert meine Begeisterung für die Zahlen. Zuzusehen, wie ein minutenlanger Check auf die Dauer eines Tab-Wechsels schrumpft, ist ein echter Kick, und ich gebe zu, dass ich bei der Arbeit aus reiner Neugier ein TypeScript-Projekt gestoppt habe. Aber ein Tool ist nur so schnell wie das langsamste Stück deines tatsächlichen Workflows, und wenn dein Lint-Schritt auf Version 6 festgenagelt ist, hat sich die Uhr in deiner CI kaum bewegt.

Deshalb würde ich gern von dir hören, vor allem wenn du Analyser-Plugins pflegst oder stark auf sie angewiesen bist: Wenn eine native Neuschreibung deines PHP-Analysers eine zehnfache Beschleunigung verspräche, deine Framework-Erweiterungen aber sechs Monate lang kaputt ließe, würdest du am ersten Tag umsteigen oder auf die API warten?