TypeScript 10-mal schneller
(devblogs.microsoft.com)- Microsoft kündigt durch eine native Portierung des Compilers und der Tools eine 10-fache Leistungssteigerung von TypeScript an
- Deutlich schnellere Startzeiten des Editors, 10-mal kürzere Build-Zeiten und stark reduzierter Speicherverbrauch
- Bis Mitte 2025 soll eine Vorschauversion von
tscerscheinen, bis Ende 2025 sind vollständige Projekt-Builds und Sprachdienste geplant
Hintergrund der TypeScript-Leistungsverbesserung
- Der zentrale Wert von TypeScript ist eine hervorragende Developer Experience
- Je größer die Codebasis wird, desto höher ist der Nutzen von TypeScript, doch in großen Projekten treten Leistungsprobleme auf
- Es kommt zu langen Lade- und Prüfzeiten
- Es braucht ein Gleichgewicht zwischen schnellem Editor-Start und der Analyse der gesamten Codebasis
- KI-basierte Funktionen benötigen schnelle und präzise semantische Informationen
- Der Bedarf wächst, den Zustand einer Codebasis über Command-Line-Builds zu validieren
Plan für die native Portierung
- Die Arbeit an der nativen Portierung des TypeScript-Compilers und der Tools hat begonnen
- Ziele der Leistungsverbesserung:
- Deutlich kürzere Startzeiten des Editors
- Bis zu 10-mal kürzere Build-Zeiten
- Geringerer Speicherverbrauch
- Mitte 2025: Geplante Veröffentlichung einer Vorschauversion von
tscmit Type-Checking über die Kommandozeile - Ende 2025: Geplante Bereitstellung vollständiger Projekt-Builds und Sprachdienste
Code ausführen und testen
- Im TypeScript-Go-Code-Repository kann der Code gebaut und ausgeführt werden
- Das Repository enthält Anleitungen zum Bauen und Ausführen von
tscund dem Language Server - Für neue Funktionen sind regelmäßige Updates geplant
Wie viel schneller ist es geworden?
- Beim Testen der Build-Zeiten aktueller TypeScript-Projekte in mehreren populären Codebasen zeigten sich folgende Leistungsverbesserungen:
- Das Projekt VS Code mit rund 1,5 Millionen Codezeilen wurde von 77,8 Sekunden auf 7,5 Sekunden reduziert, also etwa 10,4-mal schneller
- Das Projekt Playwright mit rund 350.000 Codezeilen verbesserte sich von 11,1 Sekunden auf 1,1 Sekunden, also etwa 10,1-mal
- Das Projekt TypeORM mit rund 270.000 Codezeilen verbesserte sich von 17,5 Sekunden auf 1,3 Sekunden, also etwa 13,5-mal
- Das Projekt date-fns mit rund 100.000 Codezeilen verbesserte sich von 6,5 Sekunden auf 0,7 Sekunden, also etwa 9,5-mal
- Das Projekt tRPC mit rund 18.000 Codezeilen verbesserte sich von 5,5 Sekunden auf 0,6 Sekunden, also etwa 9,1-mal
- Das Projekt rxjs mit rund 2.000 Codezeilen verbesserte sich von 1,1 Sekunden auf 0,1 Sekunden, also etwa 11-mal
- Obwohl noch nicht alle Funktionen vollständig umgesetzt sind, wird in den meisten Codebasen eine Leistungssteigerung um mehr als das 10-Fache erwartet
- Schnelles Type-Checking und einfache Code-Navigation werden möglich
- Die Integration von KI-Tools und Unterstützung für fortgeschrittenes Refactoring werden möglich
Verbesserungen der Editor-Performance
- Lade- und Reaktionsgeschwindigkeit des Editors werden verbessert
- Ladezeit auf Basis der Codebasis von Visual Studio Code:
- Aktuell: 9,6 Sekunden → native Version: 1,2 Sekunden (etwa 8-mal schneller)
- Auch der Speicherverbrauch sinkt um etwa 50 %
- Für Aufgaben des Sprachdienstes (Autovervollständigung, Quick Info, Gehe zu Definition usw.) werden Leistungsverbesserungen erwartet
- Die Migration auf Basis des Language Server Protocol (LSP) ist im Gange
Versions-Roadmap
- TypeScript 5.8 ist bereits veröffentlicht, TypeScript 5.9 erscheint in Kürze
- Die JavaScript-basierte TypeScript-Codebasis wird in der Version 6.x weiterentwickelt
- Sobald die native Codebasis stabil ist, soll sie als TypeScript 7.0 veröffentlicht werden
- TypeScript 6 → JavaScript-basierte Version
- TypeScript 7 → nativ basierte Version
- Auch nach dem Release von TypeScript 7 sollen die Versionen 6.x noch eine Zeit lang weiter gepflegt werden
Nächste Schritte
- Weitere Informationen zu Performance, Compiler-API, LSP usw. sollen noch veröffentlicht werden
- Im GitHub-FAQ lassen sich häufig gestellte Fragen nachlesen
- Am 13. März 2025 ist eine AMA in der TypeScript-Community auf Discord geplant (10:00 Uhr PDT | 17:00 Uhr UTC)
24 Kommentare
Ich hatte den Eindruck, dass alle structural typing in den Raum werfen, ohne groß darüber nachzudenken.
Wenn man es in eine Sprache mit nominal typing wie C# oder Rust neu schreiben wollte, müsste man die grundlegende Struktur des Projekts viel zu stark verändern, also wäre das wohl nicht leicht gewesen.
Unter den Sprachen mit structural typing, die gegenüber der bestehenden JS-Basis eine höhere Performance liefern könnten, kämen wohl nur C++ oder Golang infrage, und wenn man auch die Produktivität berücksichtigt, gibt es keine echte Alternative.
Irgendwann habe ich angefangen, mich weniger mit TS zu beschäftigen, aber wenn ich solche Nachrichten sehe, werde ich doch wieder neugierig?
Wenn man in
ts, außer in wirklich unvermeidbaren Fällen, ständiganymissbraucht, ist das letztlich kaum anders, als Vanilla zu verwenden.. haDie Debatte scheint ziemlich heiß zu sein – Anders Hejlsberg hat persönlich einen Kommentar hinterlassen.
https://github.com/microsoft/typescript-go/…
Jemand, der sich wünscht, dass beim Kompilieren mit TypeScript das Ergebnis direkt als Binärdatei herauskommt
Mit Frontend kenne ich mich nicht aus … ist das etwas anderes als swc?
SWC konzentriert sich darauf, wie Babel kompatiblen JavaScript-Code zu erzeugen und sogar das Bundling zu übernehmen; hier liegt der Fokus dagegen darauf, TypeScript-Code in JavaScript umzuwandeln oder Fehler zu prüfen.
Man sagt ja, man isst sein eigenes Hundefutter – also nutzt selbst, was man gebaut hat. Aber bei einer Programmiersprache gibt mir das doch etwas zu denken.
Meiner persönlichen Meinung nach sind die Runtime-Umgebungen von JS, auf dem TS basiert, (z. B. SpiderMonkey, V8) größtenteils in C++ geschrieben, und es gibt keine in JS implementierte Runtime.
Wenn man sich außerdem anschaut, dass selbst beim JS->JS-Kompilieren mit reinem JS alles zu langsam ist und deshalb alle zu esbuild und Ähnlichem wechseln,
dann frage ich mich schon, ob man bei TS wirklich unbedingt auf Dogfooding bestehen muss.
Ich mache mir Sorgen, dass die Wartung bestehender TypeScript-Codebases später vernachlässigt werden könnte.
Das sind erfreuliche Nachrichten! Erstaunlicherweise trifft die TypeScript-Sprache von MS, anders als erwartet, wirklich viele überraschende Entscheidungen (?). Aus Sicht von MS wirkt es auch sehr klug, dass es sich dabei fast um ihr erstes Open-Source-Projekt handelt und dass man sich – anders als bei Googles Dart, das JavaScript ersetzen wollte – dafür entschieden hat, JavaScript zu ergänzen. Und auch bei dieser nativen Portierungssprache ist es überraschend, dass man, obwohl es wohl viele eigene Sprachen im Unternehmen geben dürfte, sich für Googles Go entschieden hat.
Hm, es gibt doch auf der Deno-Seite bereits eine Rust-basierte Toolchain ... warum plötzlich Go?
Sie meinen vermutlich eine Runtime wie Node; hier geht es jedoch um den Compiler der TS-Sprache selbst.
Ah, nachdem ich den Artikel etwas weiter gelesen habe, glaube ich, dass ich wegen der Aussagen darüber, dass der Editor schneller wird und so, verwirrt war.
tscist 10-mal schneller geworden. Das heißt, die Transpilierungszeit vontsnachjswurde stark verkürzt.tsentwickelt wurden, wie etwa VSCode, ist es deutlich schneller. Das bedeutet, dass die Logik schneller geworden ist, die Funktionen vontscwie die Syntaxprüfung vontsmitnutzt.Darum ging es also.
Ich habe schon erlebt, dass generische Typen mit rekursivem Aufbau so langsam wurden, dass ich zu einer Ausweichlösung greifen musste. Wenn es wirklich 10-mal schneller ist, hoffe ich, dass sich auch solche Bereiche verbessern.
Der Diskussionsthread darüber, warum Go, ist interessant.
https://github.com/microsoft/typescript-go/discussions/411
Es gibt auch vieles, worüber man nachdenken muss...
Ja, ich kann aber irgendwie auch die Gefühle der .NET-Entwickler verstehen ...
Die .NET- und Rust-Entwickler sind ziemlich wütend geworden.
Ich kann .NET nachvollziehen, aber ich denke, dass Rust eher auf derselben Ebene wie Go steht. Wahrscheinlich haben auch bereits bestehende Go-Projekte und -Bibliotheken rund um JS diese Entscheidung beeinflusst.
Die Entwicklung der Sprache C# ist zwar nicht zum Stillstand gekommen, aber allzu oft hat man das Gefühl, dass Frameworks auf Basis von C# vernachlässigt werden.
Schreibt in Go~
Darauf freue ich mich sehr.
Hacker-News-Kommentare
tscin Rust versucht habenstc: eingestelltezno: in aktiver Entwicklung und nicht mit dem Ziel einer 1:1-Entsprechung zutsc