Perry im Vergleich zu den Alternativen
Wie Perry sich zu anderen Wegen verhält, TypeScript auszuliefern: Runtimes, Compiler und plattformübergreifende UI-Frameworks. Ehrlich, mit Quellen und gemessenen Zahlen, wo es welche gibt.
Perry vs Bun
Bun ist eine All-in-One-JavaScript/TypeScript-Runtime, ein Bundler, Paketmanager und Test-Runner, der zudem Single-File-Executables erzeugen kann, indem er seine Runtime mit deinem Code bündelt. Perry geht einen anderen Weg: Es kompiliert TypeScript direkt über LLVM zu nativem Maschinencode — keine JavaScript-Engine im Binary, keine Runtime, einfach ein kleines natives Executable. Bun und Perry überschneiden sich beim TS-zu-Binary-Output, sind sich aber uneinig darüber, ob eine JavaScript-Engine in diesem Binary stecken sollte.
Perry vs Deno
Deno ist eine moderne JavaScript- und TypeScript-Runtime auf V8-Basis, mit erstklassigem TypeScript-Support, einem berechtigungsbasierten Sicherheitsmodell und einem `deno compile`-Befehl, der durch Bündelung von V8 mit deiner Anwendung ein einzelnes Executable erzeugt. Perry kompiliert TypeScript direkt zu nativem Maschinencode — kein V8 im Output, keine Runtime-Schicht, einfach ein kleines natives Binary.
Perry vs Static Hermes
Static Hermes (`shermes`) ist Metas Projekt im Forschungsstadium, einen stark typisierten Subset von JavaScript/TypeScript ahead-of-time durch die Hermes-Engine zu kompilieren, primär ausgerichtet auf React Native. Perry ist eine andere Wette auf dieselbe grundsätzliche Idee — TypeScript zu Nativ kompiliert — aber unabhängig in Rust auf LLVM gebaut, mit einem funktionierenden Compiler, 25+ nativen UI-Widgets und 10 Kompilierungszielen, die heute ausgeliefert werden. Stand Mitte 2026 muss `shermes` noch immer aus dem Quellcode gebaut werden — Perrys Benchmark-Suite hat es als Peer ausprobiert und fand keinen sauberen Installationsweg über gängige Paketmanager —, und die Hermes-V1-Engine, die Anfang 2026 zum Standard in React Native wurde, enthält die statischen Kompilierungsfeatures ausdrücklich nicht.
Perry vs Electron
Electron erlaubt dir, plattformübergreifende Desktop-Apps mit Web-Technologien (HTML/CSS/JS) zu bauen, indem Chromium und Node.js mit deiner App gebündelt werden. Perry kompiliert TypeScript direkt zu nativem Maschinencode und rendert UI über echte Plattform-Widgets — AppKit, UIKit, GTK4, Win32, JNI. Electrons Versprechen ist Web-Tech-Wiederverwendung; Perrys Versprechen sind kleine native Binaries mit nativer UI aus TypeScript.
Perry vs Tauri
Tauri ist ein Framework zum Bauen plattformübergreifender Desktop- (und zunehmend Mobile-) Apps mit einem Rust-Backend und einem Frontend, das im eingebauten Webview des Betriebssystems läuft — WebView2 auf Windows, WKWebView auf macOS, WebKitGTK auf Linux. Tauri-Apps sind dramatisch kleiner als Electron, weil das OS-Webview nicht gebündelt wird. Perry geht einen anderen Weg: gar kein Webview, kein HTML-Rendering, einfach TypeScript, das zu nativem Maschinencode kompiliert wird und echte Plattform-Widgets ansteuert.
Perry vs React Native
React Native erlaubt dir, JavaScript/TypeScript zu schreiben, das native UI auf iOS und Android ansteuert — UI-Komponenten werden über eine JS-zu-Native-Bridge (oder, in der New Architecture, eine JSI-/Fabric-Schicht mit derselben konzeptionellen Form) auf Plattform-Widgets abgebildet. Perry geht einen anderen Weg: TypeScript wird ahead-of-time zu nativem Maschinencode kompiliert, und native UI ist Teil des kompilierten Binarys, nicht eine Laufzeit-Bridge.
Electron-Alternativen für TypeScript
Vier realistische Wege für TypeScript-Desktop-Apps im Jahr 2026: Electron, Tauri, Bun-Single-File-Binaries und Perrys native Widgets. Binary-Größe, Speicherverbrauch, UI-Stack und Sprache ehrlich verglichen.