Die Geburt und der Tod von JavaScript
JavaScript läuft im Browser mit sehr wenigen Privilegien. Trotzdem betreibt es Server, Build-Tools und sogar Datenbanken. Das war kein Plan. Es war eine Reihe von Patches, die auf einer Entscheidung aus dem Jahr 1995 basieren.
Im Jahr 2014 hielt Gary Bernhardt einen Vortrag mit dem Titel „The Birth and Death of JavaScript“. Viele sehen darin eine gescheiterte Prophezeiung. Ich sehe ihn als diagnostisches Werkzeug für architektonische Reibungspunkte.
Bernhardt beschrieb einen ironischen Weg. JavaScript begann als Spielzeugsprache. Es überlebte, weil es die einzige Sprache im Browser war. Dieses Monopol machte es zur am häufigsten ausgeführten Sprache der Welt, auch wenn es technisch gesehen nicht die beste Wahl war.
Das Kernproblem ist simpel. Der Browser muss Code sicher und schnell ausführen. Diese beiden Ziele stehen oft im Konflikt.
Im Jahr 2014 lautete die Vorhersage, dass WebAssembly JavaScript ersetzen würde. Das ist nicht passiert. WebAssembly ist stabil und nützlich für Dinge wie Figma oder Google Earth. Es hat JavaScript jedoch nicht als Anwendungssprache ersetzt.
Stattdessen hat sich JavaScript mutiert. TypeScript, Bundler und neue Runtimes wie Deno oder Bun sind allesamt Versuche, die von Bernhardt identifizierten Reibungspunkte zu beheben.
Nutze diesen Vortrag nicht, um das Erlernen von JavaScript zu vermeiden. Nutze ihn nicht, um den Wechsel zu WebAssembly zu rechtfertigen, bevor du ein echtes Performance-Problem hast.
Nutze ihn, um diese Fragen zu deinem Stack zu stellen:
• Nutze ich dieses Tool, weil es die beste Lösung für dieses Problem ist? • Nutze ich es, weil es das Einzige ist, das in diesem Kontext funktioniert? • Löst die Komplexität meiner Tools ein echtes Problem oder verschiebt sie es nur an eine andere Stelle? • Wenn ich heute bei Null anfangen würde, würde ich mich dafür entscheiden?
Wenn du TypeScript auf dem Server verwendest, gewinnst du Typsicherheit, erhöhst aber den Kompilierungsaufwand. Wenn du Next.js verwendest, gewinnst du Funktionen, erhöhst aber die Caching-Komplexität. Das sind echte Kompromisse.
Der häufigste Fehler besteht darin, der Sprache die Schuld zu geben, wenn das Problem eigentlich eine schlechte Anwendung ist. Wenn du schwerfälligen synchronen Code schreibst, der den Event Loop blockiert, liegt das Problem bei dir, nicht bei JavaScript.
Hör auf, nach einem magischen Ersatz zu suchen. Fang an, deine tatsächlichen Engpässe zu messen.