Die Geburt und der Tod von JavaScript

JavaScript läuft im Browser mit geringen Berechtigungen. Dennoch betreibt es Server, Build-Tools und Pipelines. Das war kein Plan. Es war eine Serie von Patches für eine Entscheidung aus dem Jahr 1995.

Zu verstehen, warum das passiert ist, verändert die Art und Weise, wie man seinen Stack heute entwirft.

Gary Bernhardts Vortrag aus dem Jahr 2014 handelt nicht von Nostalgie. Er ist eine Diagnose architektonischer Reibung. Er stellte einen ironischen Bogen fest: JavaScript war eine Spielzeugsprache, die überlebte, weil sie ein Monopol im Browser hatte. Dieses Monopol machte sie zur am häufigsten verwendeten Sprache der Welt.

Das Spannungsfeld ist einfach. Der Browser muss Code sicher und schnell ausführen. Diese beiden Ziele stehen im Konflikt.

Im Jahr 2014 war die Wette, dass WebAssembly JavaScript ersetzen würde. Das ist nicht vollständig eingetreten. WebAssembly ist stabil und nützlich für Dinge wie Figma oder Google Earth. Aber es hat JavaScript nicht als Anwendungssprache ersetzt.

Stattdessen hat sich JavaScript mutiert. TypeScript, Bundler und neue Runtimes wie Bun existieren, um die Reibungspunkte zu beheben, die Bernhardt identifiziert hat.

Nutzen Sie diesen Vortrag nicht, um das Erlernen von JavaScript zu vermeiden. Nutzen Sie ihn nicht, um den Wechsel zu WebAssembly ohne ein Performance-Problem zu rechtfertigen.

Nutzen Sie ihn als Checkliste für Ihren Stack:

TypeScript hilft bei den Typen zur Kompilierzeit. Es schließt jedoch nicht die Lücke zwischen Ihren Typen und den Daten, die über das Netzwerk eintreffen. Sie benötigen weiterhin eine Laufzeitvalidierung.

Die wichtigste Lektion ist diese: Wissen Sie, ob Ihre Technologie aufgrund ihrer Qualität existiert oder aufgrund eines Monopols.

Ändern Sie Ihre Runtime nicht basierend auf einer Vorhersage aus dem Jahr 2014. Ändern Sie sie erst, wenn Sie gemessene Daten haben, die einen Engpass aufzeigen.

Quelle: https://dev.to/jtorchia/the-birth-and-death-of-javascript-2014-what-still-holds-and-what-doesnt-2hae