Im JavaScript/TypeScript-Universum passiert gerade ein leiser, aber grundlegender Wandel: Weg von dicken Metaframeworks und komplexem Build-Tooling, hin zu einfacheren Runtimes, weniger Build-Schritten und mehr “Use the platform”.
Bun und Deno sind mit genau diesem Versprechen gestartet. Node versucht inzwischen sichtbar, hinterherzukommen – nicht mit einem großen Knall, sondern in vielen kleinen Schritten.
Dieser Artikel geht weniger um “Wer ist schneller?” und mehr um die Trends, die dahinterstehen – und warum sie überhaupt entstanden sind. Und: Warum das alles stark an die Entstehung von Go erinnert.
Wie wir uns ins Tooling-Eck manövriert haben
Die letzten Jahre im Web sahen grob so aus:
- Frameworks (React, Vue, Svelte)
- Dann Metaframeworks (Next, Nuxt, SvelteKit, Remix)
- Dazu Bundler (Webpack, später Vite, esbuild, SWC)
- Drumherum: Linting, Testing, Storybook, DX-Tools, DevServer, Edge-Adapter
Das Ergebnis
Schneller Start: npx create-next-app und du hast in 5 Minuten ein Ding in der Cloud.
Hoher Preis später:
- Debugging über SSR, CSR, RSC, Edge-Funktionen, RPC
- Schwer reproduzierbare Bugs (lokal vs. Serverless/Edge)
- Architektur hängt plötzlich am Framework
- Personalsuche hängt am Framework (Full-Stack JS, Metaframework-Know-how)
Versteckte Kosten von Metaframeworks
Metaframeworks bestimmen Teamstruktur, Personalauswahl, Architektur und Infrastruktur – viel stärker, als man am Anfang denkt.
Du holst dir mit einem Metaframework nicht nur ein Dev-Tool ins Haus, sondern ein Organisationsmodell:
- Frontend/Backend-Trennung wird unscharf
- Fast alle müssen “Full-Stack” denken
- Dein API-Design hängt am Router deines Metaframeworks
- Dein Deployment hängt am bevorzugten Hosting-Modell (Serverless, Edge, Lambdas)
Gleichzeitig merken viele Teams: Für einen Großteil der Projekte ist das eigentlich Overkill.
Warum “No-Build” und “Boring Tech” wieder attraktiv werden
Daraus entsteht der aktuelle Gegentrend:
- No-Build oder Low-Build: möglichst wenig Bundling, möglichst viel native Module
- “Boring Tech”: einfach und stabil ist der neue Hype
- Runtime übernimmt mehr Verantwortung: Tests, Bundling, TypeScript, Linting, Devserver
Die Zahlen sprechen für sich
Der Trend lässt sich belegen:
| Projekt | Entwicklung 2024 | Quelle |
|---|---|---|
| HTMX | #1 in der Kategorie Frontend-Frameworks bei JavaScript Rising Stars 2024 (vor React und Svelte) | JavaScript Rising Stars |
| Astro | Downloads verdoppelt (185k → 364k/Woche), +10.000 GitHub-Stars, #1 in Interest/Retention im State of JavaScript Survey | npm trends, State of JS |
| Bun | Größtes Wachstum unter den Runtimes 2024, 110.000 Requests/Sekunde (fast 2x Node.js) | Stack Overflow Survey |
Auch G2 Research identifiziert Simplification als einen der drei Makro-Trends 2024 – neben Automation und Consolidation. Die Philosophie “Choose Boring Technology” (Dan McKinley, ursprünglich Etsy/Stripe) erlebt ein Revival: Weniger bewegliche Teile, weniger Raum für Fehler, mehr Produktivität.
Auch außerhalb von JavaScript zeigt sich das Muster: Go, Rust und Zig setzen von Anfang an auf integriertes Tooling – ein Compiler, ein Befehl für Build, Test, Format. Kein externes Ökosystem nötig, um produktiv zu sein.
Man sieht das an vielen Stellen:
- Libraries wie HTMX, Alpine, Lit, reine ESM-Packages
- Frameworks wie Astro, die Build nur noch dort einsetzen, wo es sein muss (Islands, Partial Hydration)
- Tools wie Bun/Deno, die komplett auf “batteries included” setzen
Die Frage, die dahinter steckt:
Warum brauche ich für eine simple Webanwendung 10 Tools und 300 Dependencies?
Bun und Deno: Runtimes, die den Trend vorgeben
Bun und Deno sind im Prinzip Antworten auf die JS-Tooling-Müdigkeit.
Gemeinsame Ideen
- TypeScript out-of-the-box
- ESM als Standard, keine CJS-Altlast
- Web-APIs direkt in der Runtime (fetch, Request, Response, WebSocket, Streams)
- Integrierter Test-Runner
- Integrierter Bundler/Transpiler
- Oft auch integriertes Linting/Formatting
Die Message:
“Du brauchst keinen Zoo aus Tools, nimm eine Runtime, die’s kann.”
Bun geht noch radikaler über Performance/Speed, Deno eher über Web-Standards und Sicherheit – aber beide ziehen in die gleiche Richtung: weniger Setup, weniger Build, mehr Standard-APIs.
Node 20+ und 24: Node läuft hinterher – aber läuft
Node ist historisch anders gewachsen:
- CommonJS, require, module.exports
- Kein TypeScript
- Kein offizieller Bundler
- Tests, Linting und alles andere als Ökosystem drumherum
In den letzten Versionen sieht man aber klar: Node versucht aufzuholen, nicht zu führen.
Konkrete Beispiele
| Feature | Beschreibung | Inspiration |
|---|---|---|
| Node Test Runner | node --test – interner Test-Runner, kein Jest/Mocha nötig | Deno/Bun |
| Permissions | Experimentell eingeschränkter Zugriff auf FS/Netzwerk | Deno |
| Mehr Web-APIs | fetch, Request, Response, URL, AbortController, Web Streams | Web-Standards |
| TypeScript-Annäherung | Erste Experimente, TS leichter direkt laufen zu lassen | Deno/Bun |
| ESM-Push | Schrittweiser Ausbau (auch wenn CJS/ESM-Mischbetrieb weiterhin nervt) | Modern JS |
Das Muster:
Node baut Features nach, die Deno/Bun von Anfang an eingebaut haben.
Das ist nichts Schlechtes – eher normal für ein Projekt mit riesiger Legacy und einem stabilen Ökosystem. Aber es zeigt klar: Der Trend kommt nicht aus Node, Node reagiert auf den Trend.
Edge als Katalysator für diesen Wandel
Edge-Runtimes (Cloudflare Workers, Vercel Edge Functions, Deno Deploy, Netlify Edge Functions) verstärken diesen Wandel massiv.
Was Edge will
- Kalte Starts in Millisekunden
- Winzige Bundles
- Web-Standard-APIs
- Oft kein klassisches Node-Environment (kein fs, kein process wie gewohnt)
Das bedeutet
- Node-Spezifika sind plötzlich ein Nachteil
- Runtimes, die von Haus aus Web-APIs sprechen (Deno, Workers, teilweise Bun), passen besser
- Metaframeworks müssen sich verbiegen, um Edge-Support zu liefern (Custom Adapters, andere Runtimes, Feature-Limits)
Dadurch entsteht eine Art Druck von außen:
- Frameworks und Libraries müssen “Edge-kompatibel” sein
- Runtimes müssen sich an Web-Standards orientieren (WinterCG ist ein gutes Beispiel für diese Angleichung)
- Build-Pipelines müssen schlanker werden, weil Edge nicht alles mag, was im klassischen Node-Server möglich war
Kurz gesagt:
Edge zwingt das Ökosystem dazu, simpler und standards-näher zu werden.
Mehr dazu, wie Edge-Plattformen auch die Modul-Systeme verändern, im Artikel Edge Computing und JavaScript-Module.
Der Trend über JavaScript hinaus
JavaScript ist nur ein Beispiel – der Trend zu integrierten Ökosystemen zeigt sich sprachübergreifend.
Rust: Cargo als Vorbild
Rust verfolgt von Anfang an eine “batteries included”-Philosophie beim Tooling. Cargo vereint Paketmanager, Build-System, Test-Runner und Dokumentationsgenerator in einem Werkzeug. Kein Gradle, kein CMake, kein Maven – Cargo ist der Weg.
Der Unterschied zu JavaScript: Bei Rust war das Tooling von Tag eins integriert. Die Sprache wurde mit dieser Erkenntnis geboren.
Zig: Null externe Abhängigkeiten
Zig geht noch weiter: Das Build-System ist Teil der Sprache selbst. Keine Abhängigkeit von Make, CMake oder Python. Cross-Compilation funktioniert out-of-the-box auf allen unterstützten Plattformen.
Das Versprechen: Ein Zero-Dependency-Toolchain, das auch als C/C++-Compiler dienen kann.
Frameworks reagieren
Auch auf Framework-Ebene zeigt sich der Trend:
- Astro liefert standardmäßig null JavaScript aus und fügt Interaktivität nur dort hinzu, wo sie gebraucht wird (Islands Architecture)
- SvelteKit kompiliert zur Build-Zeit zu Vanilla-JavaScript – kein Runtime-Overhead
- Beide setzen auf Server-first statt Client-first – eine Rückkehr zu den Ursprüngen des Webs
Die Frameworks, die wachsen, sind die, die Komplexität reduzieren statt hinzuzufügen.
Warum passiert das gerade jetzt?
JavaScript-Fatigue ist real
Der Begriff “JavaScript Fatigue” existiert seit 2015 – aber er ist aktueller denn je. Das Ökosystem bietet zu viele Optionen, zu viele Entscheidungen, zu viel Churn. Wissen von vor zwei Jahren ist heute oft nicht mehr gültig.
Die Community-Stimmung 2024 zeigt: Stabilisierung allein reicht nicht. Entwickler wollen weniger Komplexität, nicht nur langsameren Wandel.
WinterCG/WinterTC: Standards statt Fragmentierung
Ein konkreter Treiber ist WinterCG (seit Ende 2024: WinterTC) – eine Zusammenarbeit zwischen Deno, Cloudflare, Node.js und anderen, um eine gemeinsame API-Oberfläche für Server-Side JavaScript zu definieren.
Das Ziel: Code, der auf Deno läuft, soll auch auf Cloudflare Workers und Node.js laufen – ohne Anpassungen. Die “Minimum Common API” definiert den kleinsten gemeinsamen Nenner der Web-Platform für alle Runtimes.
Wer treibt, wer bremst?
Treiber:
- Neue Runtimes (Bun, Deno) – sie haben nichts zu verlieren
- Edge-Anbieter (Cloudflare, Vercel, Netlify) – sie brauchen schlanke, standardisierte Runtimes
- Framework-Autoren (Astro, Svelte) – sie profitieren von weniger Build-Komplexität
Bremser:
- Legacy-Ökosysteme – Millionen von npm-Paketen basieren auf CommonJS und Node-spezifischen APIs
- Enterprise-Anforderungen – LTS-Zyklen, Stabilität, bekannte Muster
- Metaframework-Investitionen – Teams, die tief in Next.js oder Nuxt stecken, wechseln nicht über Nacht
Blick nach Go: Der Trend ist nicht neu
Wenn man das von etwas Abstand betrachtet, wirkt das alles sehr vertraut – nämlich aus der Go-Welt.
Go ist entstanden, weil bei Google die Build- und Tooling-Komplexität (C++, Java, Makefiles, gigantische Toolchains) irgendwann einfach zu viel wurde.
Zentrale Ideen bei Go
- Extrem schnelle Kompilierzeiten
- Ein einziger Befehl:
go(build, test, fmt, mod, run) - Ein Tool, das alles orchestriert
- Standardbibliothek zuerst, Frameworks optional
- Statische Binaries, einfacher Deploy
Das ist im Kern exakt derselbe Schmerz wie im JS/TS-Universum:
“Wir haben zu viel Tooling, zu langsame Builds, zu viel Komplexität.”
Der Unterschied
- Go hat diesen Trend am Anfang seiner Existenz aufgenommen
- JS/TS hat ihn nachträglich erkannt, nachdem man sich in Build- und Metaframework-Komplexität verheddert hat
Auch in Go sieht man heute:
- Viele Projekte bleiben absichtlich nah an
net/httpund Standardbibliothek - Frameworks existieren, aber die Kultur ist eher: “simple, explicit, boring”
- Tooling dreht sich um
goselbst, nicht um zehn externe Layer
Das, was Go schon vor Jahren verkörpert hat, kommt nun endlich im JS-Ökosystem an:
- Runtimes mit integriertem Tooling
- Weniger externe Magie
- Fokus auf robuste, nachvollziehbare Architekturen
In der Praxis zeigt sich das konkret: Bei einem meiner letzten E-Commerce-Projekte fiel die Wahl auf Node.js 24 – bewusst nicht LTS, sondern die aktuelle Version. Der Grund: Node 24 bringt nativen TypeScript-Support, besseren Test-Runner und mehr Web-APIs mit. Weniger externe Tools, mehr integrierte Features. Ohne das Update von Node wäre es Deno oder Bun geworden – und genau dieser Konkurrenzdruck hat Node dazu gebracht, aufzuholen.
Wohin geht die Reise?
2025-2026: Konvergenz statt Konkurrenz
Die drei großen Runtimes (Node, Deno, Bun) nähern sich an – nicht durch Aufgabe ihrer Identität, sondern durch gemeinsame Standards. WinterTC wird dafür sorgen, dass Web-APIs überall gleich funktionieren.
Die Prognose: Bis 2026 wird die Wahl der Runtime weniger ideologisch und mehr pragmatisch. Welche Runtime passt zu meinem Deployment-Modell? Welche zu meinem Team?
Rollen werden klarer
- Node.js bleibt das Enterprise-Backbone – stabil, vorhersehbar, riesiges Ökosystem
- Deno positioniert sich für Security-first-Anwendungen und moderne APIs
- Bun wird die Wahl für Performance-kritische Anwendungen und schnelle lokale Entwicklung
Viele Teams werden Bun lokal für die Geschwindigkeit nutzen und auf Node.js deployen – die Drop-in-Kompatibilität macht das möglich.
Bestehende Projekte: Kein Grund zur Panik
Die gute Nachricht: Niemand muss über Nacht migrieren. Die Konvergenz auf Web-Standards bedeutet, dass Code heute portabler wird, nicht weniger.
Konkret:
- Neue Projekte: Können von Anfang an auf integrierte Runtime-Features setzen
- Bestehende Projekte: Profitieren von Node.js-Updates, die Bun/Deno-Features nachholen
- Legacy-Code: CommonJS wird noch Jahre funktionieren – aber ESM sollte der Standard für neuen Code sein
Wenn man all das zusammennimmt, ergibt sich ein klares Bild:
- Metaframeworks haben uns viel gebracht, aber auch versteckte Kosten (Architektur, Personalsuche, Debugging, Vendor-Lock)
- Edge und Web-Standards erzwingen mehr Einfachheit und weniger Node-Speziallogik
- Bun und Deno verkörpern diese neue Welt sehr konsequent
- Node bewegt sich jetzt Schritt für Schritt in dieselbe Richtung – aus der Defensive heraus
Die eigentliche Story ist nicht “Node vs. Bun vs. Deno”.
Die Story ist:
Das JavaScript-Ökosystem holt nach, was Sprachen wie Go schon vor Jahren verstanden haben: weniger Magie, weniger Build, mehr einfache, integrierte Werkzeuge.
Und genau deshalb lohnt es sich, diesen neuen Tools eine Chance zu geben – nicht, weil sie “hip” sind, sondern weil sie einem Trend folgen, der langfristig gesünder ist: Komplexität runter, Standards rauf.