TypeScript direkt in LLVM-Maschinencode kompilieren: „Perry“, ein nativer Compiler
(github.com/PerryTS)Das bisherige TypeScript-Entwicklungsparadigma beruhte selbstverständlich darauf, TS-Code als hochabstrakte Sprache zunächst nach JavaScript zu transpilierten und ihn anschließend auf schweren JIT-Runtime-Engines wie V8 oder JavaScriptCore (Node.js, Bun, Deno usw.) auszuführen.
Perry, das kürzlich in der Open-Source-Szene aufgetaucht ist, räumt mit diesem traditionellen Runtime-Modell vollständig auf und ist ein in Rust geschriebener Native-First-Compiler, der darauf abzielt, TypeScript-Code direkt in standalone native Binärdateien zu kompilieren.
💡 Kernarchitektur und Merkmale
-
No Runtime (keine Runtime): Ohne schwere Zwischenschichten wie die V8-Engine, Electron oder die JVM wird TS-Code mit SWC geparst und über die LLVM-Infrastruktur direkt in Maschinencode für die Zielplattform gebaut.
-
Plattformübergreifende Builds aus einer Codebasis: Aus einer einzigen TypeScript-Codebasis werden Binärdateien erzeugt, die macOS, iOS, Android, Linux und Windows unterstützen.
-
True TypeScript Support: Anders als AssemblyScript, also keine „separate TS-ähnliche Sprache“, sondern mit dem Ziel, das vollständige TypeScript-Ökosystem auf Basis des Strict Mode zu unterstützen.
-
Kompatibilität mit ultraleichten UI-Frameworks: Binärgrößen von nur wenigen MB und ein Cold Start im Subsekundenbereich nahe 0 ms. Neben der Anbindung an plattformnative GUIs wie SwiftUI, GTK4 und WinUI ist auch JSX über einen eigenen React-Renderer möglich.
🛠️ Entwicklungsstand und Einschränkungen (unter Berücksichtigung des Hacker-News-Feedbacks)
Da das Projekt zuletzt unter anderem auf HN heiß diskutiert wurde, werden auch die Aufgaben auf dem Weg zur Production-Reife klar benannt.
-
Einschränkungen bei dynamischen JS-Eigenschaften: Dynamische JavaScript-Stile wie das Einspeisen beliebiger Felder/Methoden in Objekte zur Laufzeit oder das Verändern von Prototypen werden aufgrund der statischen Kompilierung nicht unterstützt; stattdessen basiert das System auf einer strikten und deterministischen TypeScript-Teilmenge.
-
Emulation eingebauter Node.js-Module: Derzeit wird die HTTP-Standardbibliothek von Node.js auf Basis des Rust-Ökosystems mit hyper, rustls, tokio usw. emuliert. Einige Module wie Fastify lassen sich bereits kompilieren, und die Entwicklung schreitet schnell voran. Die 100%ige Kompatibilität mit komplexeren Bibliotheken aus dem Ökosystem, etwa Express mit seinen verschachtelten dynamischen Imports, ist jedoch noch eine Aufgabe der Alpha-Phase.
# Die Verwendung ist extrem einfach
$ perry compile src/main.ts -o myapp
$ ./myapp # Ausführen einer reinen nativen Binärdatei ohne Abhängigkeiten
Als Versuch, TypeScript aus seiner Bindung an das Web-Ökosystem zu lösen und auf Systemprogrammierung sowie ultraleichte native Apps auszuweiten, ist dies ein Projekt, das für alle spannend zu beobachten sein dürfte, die sich für performante Systemarchitekturen oder LLVM-Compiler-Pipelines interessieren.
GitHub: https://github.com/PerryTS/perry
7 Kommentare
Ich unterstütze das.
Ein interessanter Ansatz. Allein die Beseitigung der Runtime ist schon ein großer Erfolg!
Irgendwie wirkt das plausibel. Aber ehrlich gesagt habe ich das Gefühl, dass die Speichersicherheit ein ernstes Problem sein könnte.
Und wenn kein dynamischer Lookup nötig ist, gibt es dann überhaupt einen Grund, von vornherein mit einer Skriptsprache zu entwickeln?
„Perry“ klingt gut.
Interessant.
Ich finde die Idee bzw. den Ansatz wirklich sehr gut.
Es scheint auch React-Syntax zu unterstützen, und wenn man sieht, dass Dinge wie Decorators noch nicht unterstützt werden, wirkt es so, als wäre es vorerst eher etwas, das man bei neuen Projekten ausprobieren könnte, statt bestehende Programme zu migrieren.
Wenn es dem Fahrplan entsprechend auf ein Niveau kommt, bei dem eine Migration ohne nennenswerte Kosten möglich ist, dann dürfte Multi-Plattform-Building mit einer einzigen Sprache noch sauberer werden als jetzt, und auch viele Performance-Engpässe, die bisher durch Multi-Plattform-Builds auf Basis von JavaScript entstanden sind, könnten verschwinden.
Allerdings denke ich, dass Kompatibilität und die Garantie identischer Ergebnisse auf mehreren Plattformen extrem schwierig sein werden. Und aus meiner bescheidenen Sicht dürfte auch die Wartung selbst im Zeitalter der großen KI nicht einfach sein, sodass vor allem der Entwickler enorm leiden dürfte. Davon abgesehen bin ich wirklich sehr gespannt.
Interessant.