Transcript
00:00:00TypeScript hat gerade einen Release Candidate für Version 7 veröffentlicht und das wird die Version sein,
00:00:04in der TypeScript nicht mehr TypeScript ist. Falls ihr nicht auf dem Laufenden seid: Sie arbeiten daran,
00:00:07den TypeScript-Compiler von TypeScript selbst auf Go umzuschreiben, und anscheinend sind die Ergebnisse 10-mal schneller.
00:00:12Sie planen, TypeScript 7 im nächsten Monat zu veröffentlichen. Gehen wir also durch, was sich tatsächlich geändert hat,
00:00:17wie schnell es ist und ob es Breaking Changes gibt, die ihr vor der Installation kennen müsst.
00:00:26Falls ihr die Nachrichten über die Portierung auf Go verpasst habt: Sie haben damit vor etwa einem Jahr begonnen
00:00:29und die Kurzfassung ist, dass sie erkannten, dass JavaScript nie für die rechenintensive Arbeit ausgelegt war,
00:00:34die ein Type-Checker leistet. Also begannen sie mit großem Erfolg, es in Go umzuschreiben. Sie begannen eigentlich damit,
00:00:39die bestehende Implementierung von TypeScript im Grunde Zeile für Zeile zu portieren, sodass die Typ-Prüflogik
00:00:44strukturell genau gleich war und dasselbe Verhalten aufwies. Man konnte sogar sehen,
00:00:48dass einige Funktionen bis auf die Sprache fast identisch waren. Ich bin mir auch ziemlich sicher, dass dies war, bevor
00:00:52man einfach Claude auf seine Codebasis ansetzen und sagen konnte: migriere das in die Sprache, die du willst.
00:00:56Ich schaue auf dich, Bun. Die Ergebnisse der Portierung sprechen tatsächlich für sich. Hier habe ich das
00:01:00Playwright-Repository, und wenn ich eine Typ-Prüfung mit der alten Version von TypeScript durchführe, sehen wir hier,
00:01:04dass dies etwa sechs Sekunden dauert. Und es wurden 1400 Dateien und eine halbe Million Zeilen
00:01:08Code durchlaufen. Wenn ich jetzt zum Release Candidate wechsle, ohne etwas außer diesem Befehl zu ändern,
00:01:12hat es insgesamt 0,87 Sekunden gedauert. Das ist eine ernsthafte Verbesserung. Es hat auch die exakt gleiche Anzahl an
00:01:18Fehlern gefunden, die gleichen Fehler; es hat die gleichen Dateien und alle Codezeilen durchlaufen, also funktioniert es genau
00:01:23so wie TypeScript 6. Der native Go-Code ist für eine Aufgabe wie diese einfach grundlegend schneller als JavaScript,
00:01:27aber es ermöglicht ihnen auch die Nutzung von Shared-Memory-Parallelität. Wo der JavaScript-Compiler
00:01:32single-threaded war, kann Go diese Typ-Prüfung tatsächlich auf mehrere Kerne gleichzeitig verteilen. In TypeScript
00:01:377 kann man es tatsächlich mit einem Flag dazu zwingen, single-threaded zu sein, vielleicht weil man gerade debuggt
00:01:41oder auf einer Maschine mit begrenzten Ressourcen arbeitet. Und wenn ich das in der Playwright-Codebasis
00:01:46hier mit TypeScript 7 mache, sehen wir, dass es im Single-Thread-Modus etwa zwei Sekunden dauert, was
00:01:50immer noch dreimal schneller ist als zuvor. Apropos paralleles Ausführen: Sie stellen auch
00:01:54ein neues Checkers-Flag bereit, mit dem man einstellen kann, wie viele Type-Checker-Worker parallel laufen können,
00:01:58und dies ist standardmäßig auf vier eingestellt. Dies zu erhöhen könnte bei größeren Codebasen die Builds beschleunigen,
00:02:03wenn man viele CPU-Kerne hat, aber es geht auf Kosten des zusätzlichen Speicherverbrauchs. Wenn ich die Checkers
00:02:08in diesem Playwright-Repository auf acht setze, was das Doppelte des Standards ist, scheint es tatsächlich noch ein
00:02:12Drittel der Zeit einzusparen. Es gibt auch ein neues Builders-Flag zur Parallelisierung von Projekt-Referenz-Builds, also zum Bauen
00:02:16mehrerer Projekte gleichzeitig, und mit diesem Flag kann man die Anzahl der parallelen Builder steuern, die
00:02:20gleichzeitig laufen können. Es ist erwähnenswert, dass man, wenn man dies mit den Checkern kombiniert, die wir gerade gesehen haben –
00:02:24nehmen wir an, man hätte vier von jedem – bedeutet, dass man jetzt bis zu 16 Type-Checker gleichzeitig laufen lassen kann. Neben
00:02:29den Änderungen am nativen Code und der Parallelität war ein weiteres großes Rewrite in TypeScript 7 der Watch-Modus.
00:02:34Bei der Portierung auf Go war das etwas kniffliger, da die Standardbibliothek keine
00:02:38eingebauten Dateiüberwachungs-APIs bereitstellt und die Bibliotheken von Drittanbietern, die sie ausprobierten, Probleme mit Dingen wie
00:02:43Stabilität, Leistung und plattformübergreifender Unterstützung hatten. Also schaute sich das Team den Datei-Watcher des
00:02:47Parcel-Bundlers an, den Microsoft eigentlich ein bisschen in VS Code verwendet. Aber da er in C++ war, mussten sie auch
00:02:53die Teile, die sie brauchten, ebenfalls nach Go portieren. Die gute Nachricht ist jedoch, dass sie alles geschafft haben
00:02:57und es scheint wirklich reibungslos und besser als zuvor zu funktionieren. Als Nächstes, da dies
00:03:01ein Major-Version-Sprung ist, erwartet man vielleicht viele Breaking Changes, besonders da es ein großes
00:03:05Rewrite ist, aber ich glaube eigentlich nicht, dass es welche gibt, wenn man von TypeScript 6 auf 7 aktualisiert. Wenn man
00:03:10von 5 auf 7 wechseln möchte, wird es einige geben, daher empfehlen sie anscheinend,
00:03:14zuerst auf 6 zu gehen, dort alles zum Laufen zu bringen und dann sollte das Versions-Upgrade auf 7 kein Problem sein. Ein paar der
00:03:19großen Änderungen in TypeScript 6 waren das Entfernen des ES5-Targets, das Entfernen von baseUrl und die Deprecations der Modulsysteme
00:03:24AMD, UMD und SystemJS. Sie haben auch strict auf true als Standard gesetzt, module standardmäßig auf ESNext gestellt
00:03:31und target standardmäßig auf die aktuelle stabile ECMAScript-Version unmittelbar vor ESNext gesetzt. Es war
00:03:36im Grunde ein großes Hinter-sich-Lassen der Vergangenheit und eine Modernisierung von TypeScript, was mir wirklich gefällt, da
00:03:40manchmal der Versuch, Legacy-Projekte in jeder einzelnen Version zu unterstützen, den Fortschritt eines Tools wirklich
00:03:45verlangsamen kann. Wenn man sich den Rest dieses Blogposts ansieht, scheint es tatsächlich so, dass die einzige neue
00:03:49Funktion oder Änderung, die tatsächlich die TypeScript-Sprache selbst betrifft, ist, dass Template-Literal-Typen
00:03:53jetzt Unicode-Codepunkte beibehalten. Vor TypeScript 7 hat TypeScript tatsächlich bei UTF-16-Codeeinheiten gesplittet,
00:03:59sodass es am Ende ein Emoji in zwei Hälften geteilt hat und man diese seltsamen Typen für Köpfe
00:04:04und Schwänze bekam. In TypeScript 7 hingegen splittet es tatsächlich an ganzen Codepunkten, also vollständigen Zeichen,
00:04:09sodass das Emoji jetzt erhalten bleibt und der Split ziemlich genau so ist, wie man es erwarten würde. Ich wäre
00:04:13ehrlich gesagt unglaublich beeindruckt, wenn jemand von euch jemals darauf gestoßen ist, während er TypeScript benutzt hat.
00:04:18Alles in allem sollten diese Änderungen dazu führen, dass sich alles, was TypeScript verwendet, viel schneller anfühlt, wie TypeScript
00:04:22in eurem Editor, besonders bei großen Projekten. Die stabile Veröffentlichung wird in etwa einem Monat erwartet,
00:04:27aber eine stabile programmatische API, also das, was Tooling-Autoren verwenden, um auf dem Compiler aufzubauen,
00:04:32kommt in Version 7.1. Aus diesem Grund gibt es auch ein Kompatibilitätspaket, sodass ihr
00:04:36TypeScript 6 und 7 nebeneinander ausführen könnt, ohne in Konflikte zu geraten. Lasst mich wissen, was ihr von all
00:04:41dem haltet, und ich bin neugierig, ob ihr jemals das Gefühl hattet, dass TypeScript langsam war. Lasst es mich in den
00:04:44Kommentaren wissen. Während ihr dort unten seid, abonniert und wie immer: Wir sehen uns beim nächsten Mal.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video