Die Geburt und der Tod von JavaScript (2014)

• Verfolgt die Geschichte von JavaScript und des Programmierens von 1995 bis 2035 im Stil von Science-Fiction, Komödie und ernsthaftem Vortrag
• Der Umfang beschränkt sich nicht nur auf JavaScript, sondern erweitert sich auf die Geschichte des Programmierens insgesamt
• Nimmt eine neutrale Perspektive auf JavaScript ein, ohne klar dafür oder dagegen Stellung zu beziehen
• Behandelt die Mängel der Sprache offen, bewertet ihren letztlichen Einfluss auf die Branche jedoch sehr positiv
• Die Kernbotschaft ist, dass JavaScript trotz seiner Mängel einen großen positiven Einfluss auf die Programmierbranche hinterlassen hat

---

Überblick über den Vortrag

• Verfolgt die Geschichte von JavaScript und des Programmierens insgesamt von 1995 bis 2035
• Der Vortrag ist eine Mischung aus Science-Fiction, Komödie und völlig ernsthaftem Vortrag
• Es ist kein Vortrag, der JavaScript unterstützt oder ablehnt, und lässt sich nicht auf eine einseitige Position reduzieren
• Die Mängel von JavaScript werden offen behandelt, doch sein letztlicher Einfluss auf die Branche wird sehr positiv bewertet

[GN⁺]

Hacker-News-Kommentare

• Er hat ziemlich genau vorhergesagt, dass es 2020–2025 zu einer globalen Katastrophe kommen würde, nur die Art der Katastrophe war falsch, was irgendwie schön ist(?)
  Ganz typisch JavaScript

  • Man könnte sagen, es war mit fast NaN % Genauigkeit richtig

• Ich bin überrascht, dass noch niemand erwähnt hat, dass dieser Mann uns dieses Meisterwerk hinterlassen hat
  Falls ihr es noch nicht gesehen habt: Hört auf mit dem, was ihr gerade tut, und schaut es euch an. Die besten 5 Minuten eures Tages sind garantiert
  https://www.destroyallsoftware.com/talks/wat

  • Seine Vorträge sind alle großartig
    Boundaries war das aufschlussreichste Video über Softwarearchitektur, das ich je gesehen habe, und ich denke bis heute an seine Lektionen, wenn ich komplexe Anwendungen entwerfe
    Es ist auch ein guter Einstieg dafür, Menschen, die an imperative Logik mit überall verteiltem Zustand gewöhnt sind, beizubringen, wie funktionale Programmierer zu denken
    https://www.destroyallsoftware.com/talks/boundaries
  • Dieser Vortrag enthält ein paar Fehler, und ich nenne nur zwei, die mir aufgefallen sind
    Nach dem Aufruf von Array(16) sagt er, es gebe 16 Trennzeichen, tatsächlich sind es aber nur 15, wodurch der Batman-Witz etwas kaputtgeht
    Außerdem benutzt er {}+[], erklärt, er addiere ein Objekt zu einer Liste, und macht sich dann darüber lustig, dass das Ergebnis anders ist als bei []+{}, was [object Object] ergibt; tatsächlich bekommt man mit ({}+[]) aber ebenfalls [object Object]
    Warum {}+[] anders ist, bleibt als Rätsel offen. Hinweis: Gurer vf ab bowrpg gurer.

• JavaScript wurde tatsächlich zu einem Kompilierungsziel; im damaligen Video war es asm.js, heute gibt es WebAssembly
  Wenn man sieht, dass das tatsächlich implementiert wurde und fast mit nativer Geschwindigkeit läuft, war die Vorhersage ziemlich treffend
  Ich nutze hauptsächlich TypeScript, und dank Electron wurden Web-Technologien als Desktop-Apps verpackt, wodurch die Web-Syntax auch in gewöhnliche Programme eingezogen ist
  Über Electron wird zwar gesagt, es sei schwergewichtig und nicht besonders gut, aber es ist auch der schnellste Weg, Mac, Windows und Linux gleichzeitig zu unterstützen
  Der hier gemeinte „Tod“ ist ein Zustand, in dem man JavaScript nicht mehr direkt schreibt, es aber zur überall vorhandenen Basisschicht wird, und ich denke, genau das ist passiert

  • Es gibt auch Flutter, das nicht nur Desktop-Betriebssysteme, sondern auch iOS und Android unterstützt
    Ich finde auch, dass die Entwicklungsgeschwindigkeit ziemlich hoch ist
    Wie es leistungsmäßig im Vergleich zu Electron oder nativen Apps aussieht, weiß ich allerdings nicht gut
    Für kleine Teams ist es viel sinnvoller, sich auf tatsächlich ausliefern statt auf Geschwindigkeitsoptimierung zu konzentrieren
  • JavaScript ist sozusagen die neue Assemblerschicht
    Compiler übersetzen per Definition für Menschen lesbaren Code in Maschinencode
    Der Vorteil von JavaScript ist, dass Google es mit V8 bis ans Limit getrieben hat und NodeJS im Backend eine attraktive Umgebung geschaffen hat, danach war es wie PDF überall vorhanden, und was einmal dafür geschrieben ist, kann überall genutzt werden
    Dass es gegenüber WebAssembly bisher im Vorteil war, liegt auch an dieser Vielseitigkeit; WebAssembly ist nicht annähernd so weit verbreitet wie JavaScript
    Heutzutage ist JavaScript praktisch ein Synonym für TypeScript geworden, und das war ein riesiger Sprung. Der heimliche Held dabei war meiner Meinung nach Angular 2
    Angular hat von Anfang an auf TypeScript gesetzt und zwar auch eine native JavaScript-Version angeboten, aber ehrlich gesagt war diese Version kaum brauchbar und wurde damals heftig kritisiert
    Interessanterweise ist React die letzte Zuflucht, die TypeScript nicht als Standardoption nach vorn stellt, aber da wichtige Projekte wie NextJS standardmäßig auf TypeScript setzen, wird auch ReactJS am Ende nachgeben
    Es ist nicht das erste Mal, dass Innovation zuerst in anderen Projekten auftaucht und ReactJS dann nachzieht; auch hier finde ich, dass Angular vorne lag
    Wenn man JavaScript und Python wählt, liegt man nur selten wirklich falsch
  • Wenn mit diesem „Tod“ gemeint ist, dass JavaScript zu einer Basisschicht wird, die nicht mehr direkt geschrieben wird, dann scheint das eine andere Zeitlinie zu sein als die, in der ich lebe
    Die Leute schreiben immer noch gewaltige Mengen an JS direkt, und WebAssembly hat die allgemeine Laufzeitumgebung für Webanwendungen noch immer nicht übernommen
    Man kann zwar Unternehmen finden, die etwas auf WebAssembly aufbauen, aber das darf man nicht mit der Art von großer Transformation verwechseln, von der Gary sprach
  • In der Darstellung im Video wurde JIT so gut, dass virtueller Speicher und Speicherschutz verschwanden
    Das ist überhaupt nicht passiert
  • Warum überhaupt eine App bauen, wenn eine Website ausreicht?
    Dafür muss man nicht mehrere Webbrowser laufen lassen

• Alle paar Jahre erfindet man ein besseres JavaScript und transpiliert es dann wieder nach JavaScript

  • Große Verbreitung schlägt immer gutes Design
  • Am Ende ist sowieso alles Assemblercode
    Daran, nach JavaScript zu kompilieren, ist grundsätzlich nichts falsch, und Hochsprachen können viele Garantien implementieren, die reines JavaScript selbst nicht direkt bietet
    Fast jede Sprachgarantie, die wir bisher genutzt haben, kann auf rohem Assembler gebrochen werden

• Das Problem ist, dass sich Wasm nicht so schnell weiterentwickelt hat, wie hier vorhergesagt wurde
  Da es keine DOM-Manipulation gibt, muss man JS weiterhin als Glue Code verwenden, oder man gibt HTML und CSS ganz auf und rendert wie bei Flutter oder einigen Rust-GUIs alles auf einem Canvas
  Es ist aber schade, den Funktionsumfang des Webs zu verlieren

  • Wer sich für Flutter entscheidet, wird wohl meinen, dass die Konsistenz eines Canvas in allen Browsern wertvoller ist, als einen uneinheitlich implementierten Web-Funktionsumfang zu bekommen
  • DOM und JS sind untrennbar miteinander verbunden
    Die DOM-API wurde unter der Annahme entworfen, dass man über JS darauf zugreift, und das Design von JS sowie einige seiner „eigenwilligen“ Eigenschaften stammen teilweise auch daher, dass es zusammen mit dem DOM verwendet werden sollte
  • JS ist viel zugänglicher als WASM
    Man kann es direkt debuggen, es in ein LLM werfen, und da es keine Wrapper gibt, ist es deutlich leichter, daran herumzuspielen, zu experimentieren und damit zu arbeiten

• Ich habe Gary Bernhardt 2014 auf der Canadian Undergraduate Software Engineering Conference (CUSEC) diesen Vortrag live halten sehen
  PNaCl war gerade im Jahr davor erschienen, und Google nutzte es in Chrome und ChromeOS, um OpenSSH- und RDP-Clients querzukompilieren, auszuführen und zu sandboxen, während Mozilla/Firefox als Reaktion darauf asm.js vorschlug
  Damals fand ich es einfach nur lustig, aber rückblickend ist es erstaunlich, wie viele Teile dieser Idee überlebt haben

• Gary Bernhardts Wat-Lightning-Talk war mein absoluter Lieblingsvortrag
  Er entstand gerade einmal 2 Jahre vor dem im Titel dieses Artikels erwähnten Vortrag
  [1]: https://www.destroyallsoftware.com/talks/wat

• Fast alles ist nach Drehbuch passiert
  Jetzt müssen wir nur noch auf ein weiteres Betriebssystem warten, das vollständig auf Browser-Technologien basiert, oder auf ein WASM-OS
  webOS und Firefox OS waren ihrer Zeit zumindest 20 Jahre voraus

  • Überhaupt nicht
    WASM bestätigt diese These nicht, sondern widerlegt sie
    Die These lautet, dass JavaScript-kompatibler Sourcecode die Grundlage der Zukunft wird und dass hochoptimierte JavaScript-Engines, die eine kompatible Teilmenge effizient interpretieren, zur universellen Plattform der Zukunft werden könnten, obwohl normales JavaScript selbst eine miserable Grundlage ist
    WASM weist das grundlegend zurück, indem es eine neue Grundlage schafft, die nicht mit JavaScript kompatibel ist und als Low-Level-Target entworfen wurde
    Zu sagen, WASM bestätige diese These, ist ungefähr so seltsam, als zu behaupten, eine Zukunft, in der alle einen Rust-Interpreter im Browser haben, bestätige diese These
    Wenn man so argumentiert, sagt man am Ende nur, dass Webbrowser irgendeine Form von Code in irgendeiner Sprache ausführen werden, und das tun sie bereits
    Im Video geht es eindeutig um „erstaunliche“ Möglichkeiten; zu behaupten, es sei buchstäblich mit jeder ganz gewöhnlichen möglichen Zukunft vereinbar, ergibt keinen Sinn
  • Gibt es einen technischen Grund, warum ChromeOS nicht erwähnt wurde?
    Ich frage aus reiner Neugier
    Und die webOS-Screenshots, die ich gesehen habe, haben mich auf eine Wiederbelebung hoffen lassen. Nicht nur auf Smart-TVs, sondern auch anderswo

• Wir sind bereits bei der Hälfte von Bernhardts Zeitplan bis 2035 angekommen
  JavaScript ist noch nicht tot, aber es scheint eindeutig gerade innerhalb von WebAssembly seinen eigenen Nachruf zu schreiben

  • Gut möglich, dass der letzte JS-Befehl noch ausgeführt wird, lange nachdem mehrere Generationen deiner Familie gestorben sind
    Sofern es keinen globalen Atomkrieg gibt, würde ich darauf wetten, dass JS die meisten Menschen überlebt
  • Ich prüfe jeden Monat die Websites mehrerer Kunden, und alle verwenden JavaScript in irgendeiner Form
    Wie PHP wird es niemals sterben

• JavaScript ist die beste Programmiersprache aller Zeiten