TypeScript 7 offiziell veröffentlicht – und Mann, ist das schnell!
BBetter Stack
Computing/SoftwareInternet Technology
Transcript
00:00:00TypeScript 7 wurde offiziell veröffentlicht, und nach mehr als einem Jahr akribischer Entwicklung
00:00:05hat die Portierung des Compilers nach Go gezeigt, dass man das Ganze tatsächlich mit KI erledigen kann. Ich bin mir
00:00:10sicher, dass die Entwickler darüber erfreut sind. Wenn Sie jetzt „npm install typescript“ ausführen, erhalten Sie Version
00:00:167 – also die Version mit dem Go-Compiler. Nach dem Ankündigungsvideo von Microsoft
00:00:20vor ein paar Tagen wollte ich genauer hinschauen, wie sie diese gewaltigen Performance-
00:00:25Gewinne erzielt haben. Die Ergebnisse sind wirklich beeindruckend. Der neue Compiler baut die VS Code-Codebasis,
00:00:31die aus 1,3 Millionen Zeilen Code in fast 8.000 Dateien besteht, in nur 10 Sekunden – verglichen mit den 125
00:00:39Sekunden des alten Compilers. Und da TypeScript stolz die unangefochtene Nummer eins auf
00:00:44GitHub ist – ob Sie es glauben oder nicht –, wird der neue Compiler so viele Leben verändern. Ich werde direkt emotional,
00:00:49wenn ich nur daran denke. Aber anstatt mir die fast identischen Features zwischen 6 und 7 anzusehen, wollte ich herausfinden,
00:00:54wie diese Performance genau erreicht wird. Werfen wir also einen Blick auf den neuen Compiler und sehen wir,
00:00:59was ihn so schnell macht. Warum also der Rewrite? Der Erfinder von C# und Technical Fellow bei Microsoft,
00:01:09Anders Hejlsberg, hat es ganz auf den Punkt gebracht: JavaScript ist für Benutzeroberflächen und Browser optimiert. Es ist nicht wirklich
00:01:16für rechenintensive Workflows und Compiler optimiert. Der Grund liegt auf der Hand: Es läuft single-threaded,
00:01:22und die Verarbeitung von Dingen wie einem abstrakten Syntaxbaum oder Type-Checking skaliert
00:01:27mit Zugriff auf nur einen einzelnen Kern nur begrenzt. Man könnte die Arbeit technisch gesehen auf Worker verteilen,
00:01:32müsste dann aber die Daten serialisieren und deserialisieren, was langsam und speicherintensiv ist. Und dann müsste man
00:01:38sich mit der Komplexität herumschlagen, all das zu verwalten. Also hat man sich für Go entschieden, was drastische
00:01:43Performance-Verbesserungen bietet – mit einer Sprache, die im Grunde genau für diesen Zweck gemacht ist. Go ist eine kompilierte Sprache,
00:01:48was bedeutet, dass kompilierter Code direkt auf der CPU ausgeführt werden kann, anstatt interpretiert werden zu müssen. Und Go bietet ein
00:01:54hervorragendes Nebenläufigkeitsmodell, mit dem wir problemlos mehrere Ausführungsthreads gleichzeitig ausführen können –
00:02:00und das mit gemeinsam genutztem Speicher. So können wir alle Kerne unseres Rechners nutzen statt nur
00:02:06eines einzigen. Die Beschleunigung verteilt sich etwa gleichmäßig: Bis zu die Hälfte geht auf das Konto von nativem Code,
00:02:12der Rest stammt aus der Nebenläufigkeit mit gemeinsamem Speicher. Go ist im Grunde die perfekte Sprache dafür.
00:02:17Es liegt nicht nur daran, dass Go schneller ist; es hat buchstäblich mehr Ressourcen, die es auf das Problem ansetzen kann, und die Ergebnisse
00:02:23sprechen für sich. Wenn wir uns die Zahlen ansehen: VS Code mit 1,3 Millionen Zeilen Code brauchte beim alten Compiler 125,7 Sekunden,
00:02:32jetzt 10,6 Sekunden – eine 11,9-fache Verbesserung. Bei Bluesky gingen wir von 24,3 auf 2,8 Sekunden – eine 8,7-fache Verbesserung.
00:02:42Und bei Playwright sanken die Werte von 12,8 Sekunden auf 1,5 – ebenfalls 8,7-mal schneller. Und lustigerweise dauert es nur
00:02:49eine Sekunde, Better Stack zu abonnieren. Die Lücke wird sich künftig nur noch weiter vergrößern, da Kerne nicht mehr
00:02:54im selben Tempo schneller werden wie früher. Was wir aber bekommen, sind mehr Kerne. Ich sitze zum Beispiel an einem M3 Max
00:03:00mit 14 Kernen, was verrückt ist. Ich erinnere mich noch daran, wie ich im Studium einen Gaming-PC mit einem
00:03:06Intel i7 mit vier Kernen gebaut habe – und dachte, das wäre ein absolutes Biest. Der JavaScript-Compiler würde nur
00:03:11einen dieser Kerne nutzen, aber mit Go schalte ich sie alle frei. Und je mehr Kerne man hat, desto mehr
00:03:17Performance erhält man natürlich. Wenn ich ein großes Projekt auf dieser Maschine in Version 6 kompiliere, sieht man, dass es 45
00:03:24Sekunden dauert. Mit Version 7 können wir das auf gerade einmal drei Sekunden drücken. Und es gibt mehrere
00:03:29Phasen im Kompilierungsprozess, wobei die Typprüfungsphase nur eine davon ist. Dafür wird Go
00:03:34vier Type-Checker starten und jeden ein Viertel der Codebasis prüfen lassen. Aber das lässt sich tatsächlich
00:03:39noch weiter optimieren: Während der Kompilierung kann man „checkers“ auf 12 setzen, für noch schnellere Performance.
00:03:45Ich habe das VS Code-Repo auf meinen Rechner heruntergeladen, damit wir den Unterschied zwischen TypeScript 7 und 6 sehen können.
00:03:51Standardmäßig zeigt tsc auf meinem Rechner jetzt auf TypeScript 7, also führen wir hier einfach die Diagnose aus,
00:03:57und Sie sehen, dass das 5,4 Sekunden gedauert hat. Der Großteil der Zeit entfiel tatsächlich auf die
00:04:02Prüfzeit – nämlich 4,7 Sekunden davon. Auch das können wir beschleunigen: Wenn wir ein weiteres Flag hinzufügen,
00:04:08„checkers 12“, sieht man, wie die Gesamtzeit von 5,4 auf 3,5 sinkt. Das alles spart Zeit
00:04:15bei der Prüfung ein: Hier hatten wir 4,7 Sekunden, und das ist jetzt auf 2,9 heruntergegangen. Führen wir nun denselben
00:04:20Befehl noch einmal aus, aber diesmal mit TypeScript 6. Das wird ein bisschen
00:04:23dauern, also spulen wir im Zeitraffer vor. Nach einigem Warten sieht man, dass TypeScript 6 nach
00:04:2845,3 Sekunden fertig war – verglichen mit den 3,5 Sekunden, die wir bei Ausnutzung aller Kerne erreichen. Das ist praktisch
00:04:36eine 15-fache Verbesserung auf meinem M3 Max-Chip! Für mich kommen die 3,5 Sekunden tatsächlich dadurch zustande.
00:04:43Dabei wird natürlich etwas Leistung von anderen Prozessen abgezogen, aber wenn man gerade nichts anderes macht,
00:04:47kann man ebenso gut alle Ressourcen nutzen, die der Rechner bietet. Werfen wir einen Blick auf echten Code
00:04:52aus dem neuen Compiler, um zu verstehen, wie Go diese Performance erzielt. Hier haben wir eine „bindSourceFiles“-
00:04:57Funktion, deren Aufgabe es ist, jede Deklaration in einer Datei zu erfassen und zu ermitteln, zu welchem Scope sie gehört.
00:05:03Wir verarbeiten möglicherweise Tausende von Dateien: Wir iterieren über jede Datei, stellen eine Funktion in die Warteschlange, um sie zu binden,
00:05:09und warten dann, bis alle fertig sind. Das Schöne daran ist, dass wir uns nicht darum kümmern müssen, wie diese
00:05:14Arbeit auf die Kerne verteilt wird; die Laufzeitumgebung von Go regelt das ganz von allein. Wir erzeugen keine Threads und
00:05:20verwalten keine komplexe Kommunikation zwischen den Kernen. Wir sagen einfach: „Hier ist Arbeit“, und Go findet heraus, wie der
00:05:26Rest zu erledigen ist. In JavaScript könnten wir fast identischen Code schreiben, aber für CPU-bound Aufgaben ist das witzlos –
00:05:32es würde trotzdem alles sequenziell auf einem einzigen Thread ablaufen, selbst wenn Promises die Illusion von Parallelität erzeugen.
00:05:38Worker sind technisch gesehen ein Ausweg, aber man kann keine Objekte zwischen ihnen teilen, sondern nur rohe Bytes über
00:05:43SharedArrayBuffer. Einer Arbeitsinstanz einen geparsten Syntaxbaum zu übergeben bedeutet also, das Ganze zu serialisieren,
00:05:48hinüberzukopieren und auf der anderen Seite neu aufzubauen. Bei einer großen Datei kann das mehr kosten als die eigentliche Arbeit.
00:05:53Im Grunde sind es Dinge wie diese, die Go von Natur aus besser für CPU-bound Workloads machen: Es besitzt eine
00:05:58Laufzeitumgebung, die all diese Nebenläufigkeit für einen regelt, und gemeinsam genutzten Speicher, sodass man Objekte
00:06:03übergeben kann, ohne sie kopieren zu müssen. Abgesehen von der Kompilierungszeit ist das Erste, was Ihnen auffallen
00:06:07wird, die Geschwindigkeit Ihres Language Servers. Jeder, der schon an einer großen TypeScript-Codebasis gearbeitet hat, kennt den
00:06:13Schmerz beim Warten auf die Typprüfung. Und mein Gott, diese Intel-Macs haben das wirklich zu spüren bekommen! Ich erinnere mich an Projekte
00:06:20vor ein paar Jahren: Man öffnete das Repository und musste buchstäblich
00:06:24bis zu zwei Minuten warten, nur damit die roten Wellenlinien erschienen. Und jedes Mal, wenn man eine Änderung vornahm,
00:06:29war es einfach unfassbar mühsam. Die Developer Experience war schrecklich, und niemand wollte mehr
00:06:34an der Codebasis arbeiten. Der neue Language Server sorgt jedoch für sofortiges Feedback in der IDE: Sie können
00:06:40eine Datei öffnen, eine Änderung vornehmen und Fehler in buchstäblich Millisekunden sehen – selbst wenn Sie an
00:06:46potenziell riesigen Codebasen arbeiten. Neben der Performance ist der neue Language Server jetzt auch stabiler, sodass
00:06:51die Notwendigkeit, die IDE neu zu starten, wenn die Typprüfung mal wieder den Dienst verweigert, drastisch sinkt. TypeScript 7
00:06:57hat fehlschlagende Language-Server-Befehle um über 80 % und Serverabstürze um mehr als 60 % verringert.
00:07:04Das bedeutet weniger Laptops, die gegen Wände geworfen werden – was eigentlich ziemlich gut für die Umwelt ist.
00:07:08Wer hätte gedacht, dass Microsoft sich tatsächlich um den Planeten sorgt? Es ist übrigens auch erwähnenswert, dass dies eine Portierung ist,
00:07:13keine komplette Neuentwicklung. Das TypeScript-Team hat sehr darauf geachtet, dass der neue Compiler im Grunde
00:07:19vollständig kompatibel mit dem alten ist. Abgesehen von der Geschwindigkeit werden Sie wahrscheinlich gar keinen Unterschied bemerken. Aber
00:07:24während Sie TypeScript 7 bereits in Ihren eigenen Projekten ausführen können, müssen Sie noch darauf warten, dass Ihre Lieblings-
00:07:29Packages nachziehen. Die programmatische API fehlt noch, was bedeutet, dass jedes Package, das darauf angewiesen ist,
00:07:35auf das 7.1-Release warten muss. Pakete wie typescript-eslint, ts-jest oder ts-node werden also
00:07:42vorerst hinterherhinken. Das vollständige Release von TypeScript 7 steht zwar zum Download bereit, Sie müssen
00:07:47aber die TypeScript 7-Erweiterung für VS Code explizit installieren. Das Standardpaket wird zwar irgendwann
00:07:53aktualisiert, aber installieren Sie fürs Erste einfach diese Erweiterung. Sie heißt „TypeScript 7“ im Extension Store, und
00:07:58dann läuft alles wie erwartet. Wenn Sie mehr über den Funktionsumfang von TypeScript 7 erfahren möchten: Wir haben
00:08:03ein genau dazu passendes Video gedreht, das Sie hier sehen können. Und wenn Ihnen Analysen wie diese gefallen, abonnieren Sie
00:08:08Better Stack für mehr davon. Hoffentlich haben Sie etwas gelernt, und jetzt können Sie die Vorteile der
00:08:12rasanten Entwicklung nutzen, die Sie mit TypeScript 7 erhalten. Ich weiß auf jeden Fall, dass ich es genießen werde,
00:08:16dieses Release zu nutzen. Vielen Dank fürs Zuschauen, und wir sehen uns natürlich im nächsten Video!