ts-node vs. tsx vs. esbuild: Laufzeit-Optionen im Vergleich

1. Warum die Wahl der TypeScript-Laufzeit über Produktivität entscheidet

TypeScript-Code kann nicht direkt in Node.js laufen, denn die Node-Laufzeit versteht ausschließlich JavaScript. Jeder Ausführungspfad braucht also einen Transformationsschritt, der Typannotationen entfernt und moderne Syntax gegebenenfalls auf das Zielformat herunterkompiliert. Über viele Jahre war ts-node die naheliegende Wahl: Es bindet den offiziellen TypeScript-Compiler per Register-Hook in Node ein und führt bei jedem Start eine vollständige Typprüfung durch, bevor überhaupt eine Zeile Code ausgeführt wird. Dieser Ansatz mit voller Werktreue hat einen Preis: Die Startlatenz wächst mit der Projektgröße, weil der Compiler den kompletten Programmgraphen einliest und semantisch validiert.

tsx und der direkte Einsatz von esbuild oder swc verfolgen einen fundamental anderen Ansatz: Sie entfernen Typannotationen rein syntaktisch, ohne sie gegen das semantische Modell des TypeScript-Compilers zu prüfen. Das Ergebnis ist eine dramatisch kürzere Start- und Rebuild-Zeit, aber der Verzicht auf das Sicherheitsnetz, echte Typfehler schon während eines Dev-Runs zu erkennen. Wer diesen Kompromiss versteht, statt reflexhaft das schnellste Tool zu wählen, trifft die richtige Entscheidung dafür, ob ein Team fehlerhaften Code produziert oder durch einen zu langsamen Feedback-Zyklus ausgebremst wird.

2. ts-node im Detail: Vollständige Typprüfung, langsamer Start

ts-node kompiliert TypeScript-Dateien zur Laufzeit über die offizielle TypeScript-Compiler-API und cached das Ergebnis standardmäßig im Projektverzeichnis, um wiederholte Aufrufe zu beschleunigen. Der entscheidende Vorteil: Jede Ausführung entspricht exakt dem, was tsc auch bei einem regulären Build melden würde, inklusive strikter Typprüfung, Enum-Auflösung und Pfad-Mapping über paths in der tsconfig.json. Für Projekte, in denen ein fehlerhafter Typ zur Laufzeit teure Folgen hätte, etwa Datenbank-Migrationsskripte oder Deploy-Automatisierungen, ist diese Garantie oft wichtiger als jede Millisekunde Startzeit.

Der Nachteil zeigt sich vor allem im Watch-Modus und bei größeren Codebasen: Da der TypeScript-Compiler das komplette Typsystem im Speicher hält und bei jeder Änderung erneut prüft, wächst die Reaktionszeit proportional zur Projektgröße. In mittelgroßen Monorepos sind Startzeiten von mehreren Sekunden keine Seltenheit, was den iterativen Entwicklungsfluss spürbar bremst. Der transpile-only-Modus von ts-node schafft hier teilweise Abhilfe, indem er die Typprüfung überspringt, verliert dabei aber genau den Vorteil, der ts-node ursprünglich auszeichnet.

{
  "name": "typescript-runtime-demo",
  "scripts": {
    "dev:ts-node": "ts-node --transpile-only src/server.ts",
    "dev:ts-node-full": "ts-node src/server.ts",
    "dev:tsx": "tsx watch src/server.ts",
    "typecheck": "tsc --noEmit",
    "build": "node esbuild.config.ts",
    "test": "vitest run"
  },
  "devDependencies": {
    "ts-node": "^10.9.2",
    "tsx": "^4.16.2",
    "esbuild": "^0.23.0",
    "typescript": "^5.5.4",
    "vitest": "^2.0.5"
  }
}

3. tsx im Detail: esbuild-Geschwindigkeit für den Dev-Workflow

tsx ist ein moderner TypeScript-Runner, der intern auf esbuild aufsetzt und TypeScript- sowie JSX-Dateien rein syntaktisch in JavaScript transformiert, ohne den TypeScript-Compiler selbst aufzurufen. Da esbuild in Go geschrieben ist und ohne den Overhead eines vollständigen Typsystems arbeitet, liegt die Transformationszeit typischerweise im niedrigen einstelligen Millisekundenbereich pro Datei, selbst bei umfangreichen Dateien. Für den täglichen Entwicklungsworkflow, in dem Skripte, Node-Server oder CLI-Tools ständig neu gestartet werden, ist dieser Geschwindigkeitsvorteil der Hauptgrund für die wachsende Popularität von tsx.

Der eingebaute Watch-Modus (tsx watch) beobachtet Dateiänderungen und startet den Prozess in Bruchteilen einer Sekunde neu, was sich für lokale API-Server oder Hintergrund-Worker deutlich reaktionsschneller anfühlt als ts-node im Standardmodus. Der Kompromiss ist bewusst gewählt: tsx prüft keine Typen und meldet daher auch keine Typfehler, selbst wenn eine Funktion mit falscher Signatur aufgerufen wird. Entwicklerinnen und Entwickler verlassen sich stattdessen auf die Editor-Integration, etwa den TypeScript-Language-Server in VS Code, oder einen separaten Typprüfungsschritt, um Typfehler frühzeitig zu erkennen.

# Start the dev server with tsx in watch mode
npx tsx watch src/server.ts

# Compare cold start time against ts-node
time npx ts-node src/server.ts
# real  0m3.412s

time npx tsx src/server.ts
# real  0m0.087s

# One-off migration script, no type checking, instant start
npx tsx scripts/migrate-legacy-orders.ts

4. esbuild und swc direkt: Geschwindigkeit für Skripte und Build-Tooling

Neben Runnern wie tsx lassen sich esbuild und swc auch direkt als Bibliothek einbinden, etwa um eigene Build-Skripte zu schreiben, die TypeScript-Quellcode zu optimierten JavaScript-Bundles verarbeiten. Beide Tools sind in performanten Sprachen implementiert, Go bei esbuild und Rust bei swc, und erreichen Transformationsgeschwindigkeiten, die um ein Vielfaches über denen eines Node.js-basierten Compilers liegen. Für Build-Pipelines, in denen hunderte Dateien pro Sekunde verarbeitet werden müssen, etwa beim Bundling einer großen Applikation, ist dieser Geschwindigkeitsunterschied kein Nice-to-have, sondern entscheidend für akzeptable Build-Zeiten.

Der direkte Einsatz eignet sich besonders für einmalige Skripte und Build-Tooling, bei denen kein interaktiver Watch-Modus benötigt wird, sondern eine programmatische API mit voller Kontrolle über Plugins, Ziel-Umgebung und Ausgabeformat. Ein esbuild.config.ts-Skript kann beispielsweise mehrere Einstiegspunkte parallel bündeln, Source-Maps erzeugen und Umgebungsvariablen zur Build-Zeit einsetzen, alles ohne die Umwege eines generischen Runners. swc bietet zusätzlich eine hohe Kompatibilität zu Babel-Plugins, was den Umstieg für Projekte mit bestehender Babel-Konfiguration erleichtert.

import { build } from 'esbuild';

// Bundle multiple entry points in parallel with esbuild
async function runBuild(): Promise<void> {
  await build({
    entryPoints: ['src/server.ts', 'src/worker.ts'],
    outdir: 'dist',
    bundle: true,
    platform: 'node',
    target: 'node20',
    format: 'esm',
    sourcemap: true,
    minify: process.env.NODE_ENV === 'production',
    define: {
      'process.env.BUILD_TIME': JSON.stringify(new Date().toISOString()),
    },
  });

  console.log('Build finished, output written to dist/');
}

runBuild().catch((error) => {
  // Fail the build script with a non-zero exit code on error
  console.error(error);
  process.exit(1);
});

5. Wann Typprüfung während des Dev-Runs wirklich zählt

Die zentrale Frage lautet nicht, ob Typprüfung wichtig ist, sondern wann sie im Entwicklungszyklus stattfinden sollte. Für schnelle, iterative Arbeit an einer einzelnen Funktion oder einem UI-Bugfix bremst eine vollständige Typprüfung bei jedem Speichern den Denkfluss unnötig aus, insbesondere wenn Fehler ohnehin sofort im Editor als rote Unterstreichung sichtbar sind. Der Editor-Language-Server prüft Typen ereignisbasiert und inkrementell, was in der Praxis oft schneller reagiert als ein vollständiger Neustart über ts-node.

Typprüfung während der Ausführung selbst wird jedoch entscheidend, wenn ein Skript ohne Editor-Kontext läuft, etwa in einem Cronjob, einem CI-Runner ohne IDE oder einer Produktions-Migration, die niemand mehr live beobachtet. Auch bei generierten oder von externen APIs stammenden Typen, die sich zur Laufzeit ändern können, bringt eine explizite Typprüfung vor der Ausführung reale Sicherheit. Die pragmatische Antwort ist selten ein Entweder-oder, sondern eine bewusste Trennung: schneller Feedback-Zyklus während der Entwicklung, expliziter Typprüfungsschritt vor jedem kritischen Lauf.

6. Watch-Modus und Developer Experience im Vergleich

Im Watch-Modus zeigt sich der Geschwindigkeitsunterschied zwischen den drei Ansätzen am deutlichsten. tsx watch beobachtet das Dateisystem und startet den Prozess bei jeder Änderung in der Regel innerhalb von 100 bis 300 Millisekunden neu, unabhängig von der Projektgröße, weil nur die geänderte Datei erneut transformiert werden muss. ts-node-dev oder ts-node mit nodemon benötigen dagegen oft mehrere Sekunden, weil der TypeScript-Compiler bei jedem Neustart erneut das komplette Typsystem aufbaut, selbst wenn nur eine einzelne Zeile geändert wurde.

Für Entwicklerinnen und Entwickler bedeutet dieser Unterschied nicht nur gesparte Wartezeit, sondern einen anderen Denkmodus: Ein Feedback-Zyklus unter 300 Millisekunden fühlt sich wie eine direkte Verbindung zwischen Code-Änderung und Ergebnis an, während mehrere Sekunden Wartezeit den Kontext im Kopf verblassen lassen. Genau deshalb hat sich tsx in den letzten Jahren als Standard für lokale Node.js-Entwicklung etabliert, auch in Projekten, die für Produktions-Builds weiterhin auf den vollständigen TypeScript-Compiler setzen.

7. CI-Pipelines: Typprüfung und Ausführung sauber trennen

In einer CI-Pipeline sollte Typprüfung nie implizit als Nebeneffekt eines Testlaufs passieren, sondern als eigener, klar benannter Schritt. tsc --noEmit prüft das gesamte Projekt gegen die tsconfig.json ohne Ausgabedateien zu erzeugen und liefert einen nicht-null Exit-Code bei jedem Typfehler, was sich ideal für ein separates CI-Gate eignet. Dieser Schritt läuft unabhängig davon, mit welchem Tool die eigentlichen Tests oder Skripte anschließend ausgeführt werden.

Die Tests selbst können dann mit tsx oder einem Test-Runner wie Vitest laufen, der intern ebenfalls auf esbuild setzt und dadurch selbst bei tausenden Testfällen schnell startet. Diese Trennung hat einen praktischen Vorteil: Der Typprüfungs-Schritt und der Testlauf können parallel in unterschiedlichen CI-Jobs ausgeführt werden, was die Gesamtlaufzeit der Pipeline reduziert, statt beide Aufgaben seriell in ein einziges, langsameres ts-node-basiertes Kommando zu zwängen. Für zusätzliche Sicherheit lohnt sich ein tsc --noEmit --incremental mit gecachtem .tsbuildinfo, um wiederholte CI-Läufe weiter zu beschleunigen.

#!/usr/bin/env bash
set -euo pipefail

# Step 1: type check the whole project, no output files
npx tsc --noEmit

# Step 2: run the test suite with a fast esbuild-based runner
npx vitest run --reporter=dot

# Step 3: build production bundles with esbuild directly
node esbuild.config.ts

echo "Pipeline finished: types checked, tests passed, build complete"

8. Praxisempfehlungen je nach Anwendungsfall

Für einmalige Skripte, etwa ein Migrationsskript, das einmal ausgeführt und danach gelöscht wird, ist tsx meist die pragmatischste Wahl: kein Setup, sofortiger Start, und das Risiko eines unentdeckten Typfehlers ist überschaubar, weil das Skript ohnehin manuell beobachtet wird. Für lokale Entwicklung mit Watch-Modus, egal ob API-Server, Worker oder CLI-Tool, ist tsx ebenfalls die klare Empfehlung, ergänzt durch einen aktiven TypeScript-Language-Server im Editor, der Typfehler in Echtzeit anzeigt, ohne den Prozess neu zu starten.

Für Build-Tooling, das eigene Bundling- oder Transformationslogik benötigt, lohnt sich der direkte Einsatz von esbuild oder swc als Bibliothek, weil damit volle Kontrolle über Plugins und Ausgabeformat besteht. In CI-Pipelines gilt die klare Regel: Typprüfung immer als expliziter tsc --noEmit-Schritt, unabhängig davon, mit welchem Runner die Tests laufen. ts-node bleibt sinnvoll für Szenarien mit komplexem Pfad-Mapping oder Decorator-Metadaten, die esbuild nicht vollständig unterstützt, etwa in älteren NestJS- oder TypeORM-Projekten mit experimentalDecorators.

9. Direkter Vergleich: ts-node, tsx und esbuild/swc

Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen den drei Ansätzen zusammen und zeigt, in welchen Dimensionen sich die Tools grundlegend unterscheiden. Ein einfaches Benchmark auf derselben Datei macht den Unterschied konkret spürbar, statt ihn nur abstrakt zu behaupten.

# Cold start benchmark, 200-line TypeScript entry file, Node 20
$ hyperfine 'ts-node src/server.ts --eval-only' 'tsx src/server.ts' 'node --import ./esbuild-register.mjs src/server.ts'

Benchmark 1: ts-node src/server.ts --eval-only
  Time (mean +/- SD):      1.842 s +/-  0.091 s

Benchmark 2: tsx src/server.ts
  Time (mean +/- SD):      86.4 ms +/-   4.2 ms

Benchmark 3: node --import ./esbuild-register.mjs src/server.ts
  Time (mean +/- SD):      41.7 ms +/-   2.8 ms

Summary
  esbuild-register ran
    2.07 times faster than tsx
    44.17 times faster than ts-node

Keine der drei Optionen ist in jeder Situation die richtige Wahl. Wer ts-node, tsx und einen direkten esbuild/swc-Einsatz je nach Kontext kombiniert, statt sich auf ein einziges Tool für alle Aufgaben festzulegen, bekommt sowohl die Sicherheit vollständiger Typprüfung als auch die Geschwindigkeit eines modernen Feedback-Zyklus.

10. Zusammenfassung

Die Wahl zwischen ts-node, tsx und einem direkten esbuild/swc-Einsatz ist keine Frage nach dem einen richtigen Tool, sondern nach dem passenden Werkzeug für den jeweiligen Moment im Entwicklungszyklus. ts-node liefert vollständige Typprüfung zur Laufzeit auf Kosten der Startzeit und eignet sich für kritische Skripte mit komplexem Pfad-Mapping oder Decorator-Metadaten. tsx nutzt esbuild für einen extrem schnellen Start und eingebauten Watch-Modus und hat sich als Standard für die lokale Entwicklung etabliert, verzichtet dabei aber bewusst auf Typprüfung.

esbuild und swc direkt als Bibliothek eingesetzt liefern die rohe Geschwindigkeit für Build-Tooling und Bundling, während CI-Pipelines Typprüfung immer als eigenen, expliziten tsc --noEmit-Schritt behandeln sollten, unabhängig davon, welcher Runner die eigentlichen Tests ausführt. Wer diese drei Rollen bewusst trennt, statt ein einziges Tool für alles zu verwenden, gewinnt sowohl Geschwindigkeit im Alltag als auch Sicherheit an den Stellen, an denen sie wirklich zählt.

11. FAQ: ts-node, tsx und esbuild im Vergleich