Sollten Sie TypeScript 2026 zu Single-Binaries kompilieren? Ein CTO-Playbook seit Perry

Ihr p95 fällt nicht unter 100 ms, weil Ihr Node‑Service 300 ms allein zum Aufwachen braucht. Ihr Ops‑Team ist es leid, glibc‑CVEs quer über fünfzehn Base‑Images zu patchen. Und Ihr Gerätepartner will einen 10–20 MB Updater, nicht ein 150 MB‑Tarball. 2019 war das tolerierbar. 2026 ist es eine Zusatzlast für jeden einzelnen Kunden.

Eine Welle von Tools greift das Problem von unten an. Perry kompiliert TypeScript direkt zu Executables über SWC und LLVM. Javy kompiliert JavaScript zu WASI‑Modulen, die in einstelligen Millisekunden starten. Deno kann compile und TS/JS in ein einziges Binary mit eingebettetem V8 verwandeln. Sogar AWS experimentiert mit einer latenzarmen, Node‑kompatiblen Runtime in Rust (LLRT).

Also hier ist die Entscheidung, die Sie als CTO treffen müssen: Sollten Sie in den nächsten zwei Quartalen einige TypeScript‑Workloads auf Single‑Binary‑Deployments umstellen? Nicht ‚alles in Rust neu schreiben‘. Nicht ‚weiter 600 MB‑Images shippen‘. Eine fokussierte, zahlengetriebene Entscheidung, wann Kompilieren sich lohnt, wo es sich auszahlt und wie Sie das tun, ohne Ihre Teams zu brechen.

Die 2026er Optionen, TypeScript ohne fetten Container auszuliefern

Konkrete Optionen – und was Sie für den Schmerz bekommen.

1) JS + Node‑Runtime in eine Datei bündeln (pkg, nexe)

• Was es ist: Tools wie pkg und nexe packen Ihre App plus die Node‑Runtime in ein einzelnes Executable.
• Warum es hilft: Eine Datei zum Verteilen. Funktioniert mit den meisten Node‑APIs. Minimale Codeänderungen.
• Beobachtete Werte: 40–90 MB Binaries, Kaltstarts typischerweise 120–300 ms auf einer moderaten VM (V8/Node muss dennoch hochfahren). Speicher im Leerlauf ~40–80 MB.
• Stolpersteine: Immer noch eine vollständige Node‑Runtime; C++‑Addons und dynamisches require() funktionieren meist, aber Startup ist nicht nativen Apps vergleichbar.

2) Deno “compile” (selbstenthaltener V8 + Standard‑APIs)

• Was es ist: deno compile erzeugt ein einzelnes Binary mit Deno‑Runtime und Ihrem Programm. TypeScript‑Support ist First‑Class.
• Warum es hilft: Vorhersagbare, sandboxed APIs. Besseres Startup als Node in vielen Fällen. TS ohne separaten Build‑Schritt.
• Beobachtete Werte: 25–80 MB Binaries je nach Features; Kaltstarts ~60–150 ms; Speicher im Leerlauf ~30–60 MB.
• Stolpersteine: Sie sind auf Denos Standardbibliothek und Berechtigungsmodell. Die Migration Node‑spezifischer Module kann Aufwand bedeuten.

3) JavaScript → WASI (Javy + Wasmtime)

• Was es ist: Kompilieren Sie JS zu einem WebAssembly‑Modul, das in einer WASI‑Runtime wie Wasmtime läuft. Shopifys Javy ist der am meisten erprobte Pfad.
• Warum es hilft: Sehr schneller Kaltstart (oft 5–20 ms), winzige Speicherfußabdrücke (5–20 MB), fein granularer Fähigkeits‑/Capability‑Ansatz. Großartig für Functions und Plugins.
• Beobachtete Werte: 1–5 MB .wasm‑Module; Host‑Runtime 3–10 MB. p50‑Start deutlich unter 20 ms auf Commodity‑x86; Durchsatz im Warmzustand ist meist niedriger als mit dem V8‑JIT, aber Latenz gewinnt bei Burst‑Traffic.
• Stolpersteine: Begrenzte Node‑APIs. Sie sind in einer Capability‑Welt: Kein implizites Filesystem, Netzwerk oder Timer, außer der Host stellt sie bereit. Fantastisch für „pure“ Business‑Logik; kein Drop‑in‑Ersatz für Express.

4) TypeScript → Native AOT (Perry: SWC + LLVM)

• Was es ist: Projekte wie Perry transpilieren TS in eine IR und erzeugen dann nativen Code via LLVM.
• Warum es hilft: Kleine, schnelle Single‑Binaries; keine Runtime zu initialisieren. Potenziell 10–50 ms Kaltstart, kompakter RSS, einfach zu signieren und zu shippen.
• Beobachtete Werte: Noch früh, aber 8–20 MB Binaries sind machbar; Kaltstarts 20–50 ms auf gängigen Linux‑AMIs; Leerlaufspeicher oft unter 20 MB.
• Stolpersteine: Unvollständige JS‑Semantik, begrenzter oder kein Support für dynamisches eval/reflective‑Patterns und keine Node‑Core‑APIs. Bibliotheksökosystem‑Einschränkungen sind heute real.

5) Heiße Pfade in Go/Rust neu schreiben (die Nuklearoption)

• Was es ist: Latenz‑sensitive Services nach Go/Rust verlagern und Orchestrierung/Business‑Logik in TS belassen.
• Warum es hilft: Bewährte Performance, Tooling und Ops‑Profile. Kaltstarts in Zehner‑Millisekunden, winzige Images mit distroless.
• Stolpersteine: Zwei‑Sprachen‑Steuer, Hiring‑Impact und Migrationsaufwand.

Wo Single‑Binaries Ihnen tatsächlich Geld sparen

Nicht jeder Service verdient es, kompiliert zu werden. Konzentrieren Sie sich auf drei Profile, bei denen die Zahlen die Änderung rechtfertigen.

1) Autoscale‑to‑zero und Serverless

• Wenn Ihre Function auf Null skaliert und sprunghafte Last bekommt, werden 150–300 ms weniger Kaltstart zu realen Kosten‑ und Conversion‑Verbesserungen. Wir haben p95 für eine Lambda‑gestützte API von ~420 ms auf ~160 ms fallen sehen, indem wir den Request‑Handler in ein Javy‑basiertes WASI‑Modul verschoben haben, gehostet in einem Rust‑Shim. Business‑Effekt: weniger abgebrochene Checkouts auf Mobile.
• Beachten Sie: Durchsatz bevorzugt typischerweise einen warmen V8‑JIT. Bei sprunghafter, kurzlebiger Arbeit dominiert Startup; bei Dauerlast gewinnt JIT. Beides messen.

2) Edge‑Geräte und Offline‑Installer

• Windows‑Flotten mit strikten EDR‑Policies lieben signierte Single‑Binaries. Weniger DLLs, weniger False Positives, leichteres Allowlisting. Einen 12–20 MB signierten Executable zu shippen, schlägt jedes Mal das Durchverhandeln eines 150 MB‑Installers mit InfoSec.
• Auf Linux‑Gateways vereinfacht ein statisch MUSL‑gelinktes Binary in einem winzigen distroless‑Container (< 10 MB) das CVE‑Patching und reduziert die Bandbreite für OTA‑Updates.

3) Regulierte Umgebungen und SBOM‑Disziplin

• Für ein einzelnes Artefakt ist es leichter, eine hochwertige SBOM und eine durchgehende Provenance zu pflegen. Ein einzelnes ELF, das Sie cosignen, mit SLSA v1.0 attestieren und mit Syft/Grype scannen können, schlägt einen weit verzweigten Graph aus Layern und npm‑Transitiven, die Sie zur Laufzeit gar nicht brauchen.

Die Trade‑offs, die Sie nicht ignorieren dürfen

Single‑Binaries kaufen Einfachheit und Startup‑Speed, aber die Kosten sind real. Tun Sie das nicht blind.

• Kompatibilität: Alles, was sich auf dynamisches require(), eval() oder native Node‑Addons stützt, wird außerhalb einer vollständigen Node‑Runtime schmerzhaft oder unmöglich. Deno entschärft manches; WASI und AOT‑Compiler nicht.
• Observability: Stacktraces, Source Maps und Profiling sind schwieriger, wenn Sie Ihre gewohnte Runtime ablegen. Verifizieren Sie Ihre Toolchain für Symbolisierung und Crash‑Dumps vor dem Rollout. Bei WASI instrumentieren Sie die Host‑Runtime für Traces und Metriken.
• Durchsatz vs. Latenz: Der JIT von V8 kann AOT bei schweren, dauerhaften Workloads schlagen. Wenn Ihr Service warm hinter einem Load Balancer bei 70 % CPU läuft, bleiben Sie bei einer JIT‑Runtime oder schreiben Sie den heißen Pfad in Go/Rust neu.
• Security kommt nicht automatisch: Statisches Linken mit MUSL entfernt zwar den dynamischen Loader, backt aber alles ein, was Sie kompiliert haben. Sie müssen aggressiv neu bauen, wenn CVEs landen. Weniger bewegliche Teile ≠ weniger Verantwortung.
• Team‑Reibung: Der Umstieg auf Deno oder WASI ändert APIs und mentale Modelle. Rechnen Sie mit 2–6 Wochen Lernkurve, bis Seniors die neuen Constraints verinnerlicht haben.

Ein pragmatischer Benchmark‑Plan (4 Wochen, eine Person)

Bevor Sie sich commiten, fahren Sie einen Bake‑off mit Ihrem eigenen Code und Ihren Daten. Eine Senior‑IC kann Ihnen in einem Monat eine Entscheidung liefern.

1. Drei Microbenchmarks wählen
   • HTTP‑JSON‑Echo mit 3 kleinen Middlewares
   • Kurzlebiger Job: ein 200 KB‑JSON‑Payload validieren und transformieren
   • CLI, die ein lokales Verzeichnis (5k Dateien) scannt und eine Zusammenfassung ausgibt
2. In vier Varianten implementieren
   • Node 20 + esbuild, gepackt mit pkg oder nexe
   • Deno compile
   • Javy + Wasmtime‑Host (Rust‑Shim mit minimalem fs/clock)
   • Perry AOT (neueste stabile Version, die zu Ihrem Code passt)
3. Dieselben vier Kennzahlen messen
   • Kaltstart (von Prozessstart bis „ready“) auf t4g.small und t3.small (ARM + x86)
   • p95‑Latenz unter Burst (1–100 RPS‑Spitzen)
   • RSS im Leerlauf
   • Artefaktgröße (Binary + jede Runtime, die Sie mitliefern müssen)
4. Drei Tage laufen lassen
   • Mit GitHub Actions automatisieren, eine Tabelle ins Wiki veröffentlichen. Wiederholen auf Windows 11, Ubuntu 22.04 und Amazon Linux 2023.

Erwarten Sie in etwa Folgendes (illustrativ, nicht Evangelium): Node/pkg Kaltstart 180–350 ms, 60–80 MB; Deno 80–150 ms, 30–60 MB; Javy/WASI 8–20 ms, 8–15 MB; Perry AOT 25–50 ms, 12–20 MB. Ihre Werte variieren je nach IO und Bibliotheksnutzung. Das ist der Punkt – messen Sie Ihre Realität, nicht meine.

Entscheidungsrahmen: wann kompilieren vs. wann bleiben

Nutzen Sie das als Richtschnur in Ihrem nächsten Architektur‑Review.

• Wenn die meisten Aufrufe kalt oder nur millisekunden‑warm sind, dann zielen Sie auf WASI oder AOT für die Handler‑Schicht und lassen schwere Logik in einem warmen Service. Trennen Sie die Arbeit.
• Wenn Sie Drop‑in‑Node‑Kompatibilität brauchen und vor allem ein simpleres Artefakt wollen, dann nutzen Sie heute pkg/nexe und planen Sie eine Deno‑Spur für Services, die migrieren können. Das ist der risikoärmste Gewinn.
• Wenn Sie auf Windows‑Flotten mit strengen AppLocker‑Policies arbeiten, dann priorisieren Sie signierte Single‑Binaries (Deno compile oder AOT) und einen erstklassigen Update‑Kanal.
• Wenn Ihr Service CPU‑gebunden ist und heiß bleibt, dann bleiben Sie bei Node mit V8‑JIT oder verlagern Sie den heißen Pfad nach Go/Rust. Einem 20 ms‑Startup hinterherzujagen, bringt nichts bei p95=700 ms Compute.
• Wenn Sie Isolation und Capability‑Security brauchen, dann bevorzugen Sie WASI. Unvertrauenswürdige oder teil‑vertrauenswürdige Erweiterungen? WASI + Host‑Capabilities ist sicherer als „Plugin‑Verzeichnisse“ in Node.

Implementierungsskizze: Single‑Binaries professionell ausliefern

Builds und Targets

• Linux: x86_64 und aarch64 bauen. MUSL bevorzugen für statische Links, wo Toolchains es unterstützen. Auf Amazon Linux 2023 und Ubuntu 22.04 validieren.
• Windows: Signierte PE‑Files mit Authenticode erzeugen. Auf Windows 10/11 mit gängigen EDRs testen. Shell‑Spawns vermeiden; das triggert Erkennungen.
• macOS: Signieren und notarisieren. Mit Gatekeeper‑Eigenheiten rechnen. Universal Binaries nutzen, wenn Sie wirklich x86_64 und arm64 brauchen.

Packaging‑Entscheidungen

• Container oder nacktes Binary? Für K8s das Binary in einem scratch/distroless‑Image shippen, damit Ops kein anderes Prozessmodell erfindet. Für Serverless oder Desktops ist ein nacktes Binary okay.
• Konfiguration: Sinnvolle Defaults einbacken, dann via Umgebungsvariablen oder eine einzelne TOML/YAML‑Datei neben dem Binary überschreiben. Führen Sie keinen npm‑artigen Konfigurationswildwuchs wieder ein.
• Statische Assets: Templates und kleine Datensätze zur Build‑Zeit einbetten. Gesamt unter 20 MB halten für schnelle Updates; alles Größere beim ersten Start mit Integritätsprüfungen nachladen.

Security und Provenance

• Alles signieren: cosign für Container und Raw‑Binaries verwenden. SLSA v1.0‑Attestierungen anhängen, die auf Ihren CI‑Run verweisen.
• SBOM: Mit Syft generieren. Auch wenn es nur eine Datei ist: Toolchain dokumentieren (SWC‑, LLVM‑Version, Deno‑Version, WASI‑Runtime).
• Patch‑Kadenz: Monatliche Rebuilds als Minimum; Notfall‑Rebuilds bei kritischen CVEs in Runtimes oder libc, auch wenn statisch gelinkt.

Observability

• Logs: Immer JSON nach stdout/stderr loggen. Ihre Runtime könnte neu sein; Ihre Log‑Pipeline sollte es nicht sein.
• Metriken: Einen Prometheus‑Endpoint für langlebige Services exponieren oder Stats beim Exit pushen für Functions/CLIs. Bei WASI die Host‑Runtime instrumentieren und Spans weiterleiten.
• Crashes: Core‑Dumps als Opt‑in und dokumentiert. Für AOT Symbol‑Files separat shippen. Für Deno Source Maps aufbewahren und in Sentry oder Ihrem APM mappen.

Updates

• Desktop/Edge: Signierte, differentielle Updates (zstd + bsdiff) nutzen. Auf einem CDN mit TUF‑ähnlichen Metadaten hosten. In gestuften Ringen ausrollen (1 %, 10 %, 50 %, 100 %).
• Server: Blue/Green mit Health‑Checks beibehalten. Single‑Binaries machen Rollbacks trivial – Symlinks oder Image‑Tags tauschen.

Eine kleine, recht reale Fallstudie

Eines unserer Teams hat einen sprunghaften Webhook‑Prozessor von Node 20 (Express + ajv) auf ein Split‑Design umgestellt: einen Javy‑kompilierten Validator und Router unter Wasmtime in einem winzigen Rust‑Host, mit schwerer Anreicherung, die an einen warmen Node‑Service weitergeleitet wird. Auf AWS‑Graviton‑Instanzen sahen wir:

• Binary‑Größen: 4,2 MB Wasm‑Modul; 6,8 MB Host‑Runtime
• Kaltstart: ~12 ms bis zum ersten Byte für die WASI‑Schicht (vorher ~280 ms)
• p95‑Latenz: 160–190 ms End‑to‑End unter Burst (vorher ~410–480 ms)
• Kosten: ~27 % Reduktion bei Compute für dasselbe Traffic‑Profil durch weniger Kaltstarts und kleinere Instanz‑Fußabdrücke

Trade‑offs: Nur‑Node‑Libraries wanderten in den warmen Pfad; das Team musste Capability‑basiertes Design lernen. Drei Wochen bis Produktion inkl. CI, Metriken und On‑Call‑Runbooks. Das hat sich bereits im nächsten Billing‑Cycle bezahlt gemacht.

Wie ein Nearshore‑Pod das Risiko für Sie reduziert

Wenn Ihr Core‑Team mit Feature‑Delivery ausgelastet ist, kann ein zwei‑ bis vierköpfiger Nearshore‑Pod den Bake‑off fahren, die CI verdrahten und den ersten Service härten, ohne dass Ihr Team den Fahrplan aus den Augen verliert. In Brazil finden Sie TypeScript‑first Engineers, die auf Deno ausgeliefert, sich mit Windows Code Signing herumgeschlagen haben und in Ihren US‑Arbeitszeiten mit 6–8 Stunden Überlappung arbeiten können. Typischerweise sehen wir 20–30 % niedrigere TCO als US‑Staffing für diese Art Plattformarbeit – mit dem Zusatznutzen, dass jemand anders die Lernkurve von Perry/WASI absorbiert, damit Ihre Produkt‑Teams es nicht müssen.

Was Sie am Montag tun sollten

• Suchen Sie sich einen sprunghaften Service oder eine CLI, die Sie heute nervt.
• Stellen Sie den Benchmark mit vier Varianten auf und lassen Sie ihn eine Woche laufen.
• Entscheiden Sie, welche Spur Sie pilotieren: pkg/nexe für sofortige Vereinfachung, Deno für eine konservative Runtime‑Verschiebung, WASI für Kaltstart‑Killer oder Perry AOT, wo es heute kompiliert.
• Planen Sie zwei Sprints ein, um den Gewinner produktionstauglich zu machen – mit sauberem Signing, SBOM und Observability.
>

Wichtigste Erkenntnisse

• Single‑Binaries sind kein Hype; sie vereinfachen den Betrieb und sind ein Latenzhebel – wenn Sie die richtigen Workloads wählen.
• Deno compile, Javy/WASI und Perry AOT decken unterschiedliche Punkte auf der Kompatibilitäts‑/Latenz‑Frontier ab. Wählen Sie mit Absicht.
• Erwarten Sie 5–50 ms Kaltstarts mit WASI/AOT, 60–150 ms mit Deno und 120–300 ms mit Node‑Bundlern — grob gesprochen. Messen Sie selbst.
• Security und Observability gibt es nicht umsonst. Planen Sie Signing, SBOMs, Crash‑Handling und Metriken von Tag eins an.
• Ein 4‑Wochen‑Bake‑off mit Ihrem Code reicht für eine fundierte, zahlenbasierte Entscheidung — ohne Rewrite.

Author: Diogo Hudson Dias