Ed Post über JavaScript (3/3)

Teil 3: Ein Fazit und eine Prognose

Ed Post1 ist wohl einer der allgemein anerkanntesten Experten im Bereich der Programmiersprachen sowie deren Ökosysteme. Wir haben Ed Post nach seiner Keynote im Commnucation Convention Center »Mitte« getroffen, um mit ihm über das Thema “Ist JS (k)eine General Purpose Sprache?” zu diskutieren. In Teil 1 dieses Interviews haben wir uns mit den wilden Jahren von JavaScript befasst, in Teil 2 sprachen wir über besondere JavaScript-Spezialitäten und im folgenden Teil 3 wagt Ed Post ein Fazit und eine Prognose zu JavaScript.

… Schon früh hat Ed Post am MIT mit seinen Thesen und Arbeiten zur Software-Programmierung auf sich aufmerksam gemacht und dabei eine Vorreiterrolle übernommen. Ihm ist es zu verdanken, dass ein allgemeines Umdenken im Bereich der Software-Entwicklung, insbesondere der Programmierung, mitte der 80er Jahre des letzten Jahrhunderts stattgefunden hat. Er hat damit den Weg in die moderne IT, wie wir sie heute kennen, erst ermöglicht …1

Zurück zur Ausgangsfrage

Frage: Kommen wir zurück zur Ausgangsfrage: “Ist JS eine General Purpose Sprache? Ja oder Nein?” (siehe Teil 1 dieses Interviews, Anm.d.Red.)

Ed Post: Am Ende des Tages nähern sich die aktuellen Programmiersprachen aneinander an. JavaScript bekommt immer mehr Konstrukte, die wir aus Python, C# oder Java kennen. So etwa das Modulkonzept ab ECMAScript 62 oder die klassenbasierte Objektorientierung ab ECMAScript 20153. Auch könnte es bald Integer-Typen in JavaScript geben4.

Ist JS (k)eine General Purpose Sprache? […]

… nun, JavaScript ist Turing-Vollständig …5… doch wer tut sich schon die Turing-Maschine als Programmiersprache an?6

Frage: Finden auch Konzepte aus JavaScript in anderen Programmiersprachen Eingang?

Ed Post: Andersherum geht es ebenso: Es finden viele funktionale Elemente Eingang in andere Sprachen, wie wir es gerade bei den JVM-Sprachen beobachten können7 oder sind schon lange Bestandteil dieser, wie etwa bei Pascal oder Smalltalk. Funktionale Programmierung gibt es ja nicht erst seit JavaScript8.

Frage: Werden wir irgendwann dann eine einheitliche Programmiersprache haben, die das Sinnvolle aus anderen Welten integriert und das weniger Sinnvolle außen vor lässt?

Ed Post: Ich glaube nicht, dafür sind die Konzepte der verschiedenen Programmiersprachen an zu vielen Stellen zu unterschiedlich. Es wird viel getan, damit man alles, was in anderen Programmiersprachen möglich ist, auch mit JavaScript realisieren kann, aber der Preis ist hoch.

Frage: Inwiefern unterschiedlich?

Ed Post: JavaScript wird interpretiert, andere Sprachen werden kompiliert. Damit verbunden ist die Frage, wann ich Fehler finde. Bei interpretierten Sprachen eigentlich erst zur Laufzeit, dafür müssen diese nicht erst zeitaufwändig kompiliert werden. Dieser Vorteil fällt weg, da das Linten wesentlicher Bestandteil bei der JavaScript-Entwicklung ist. Dann haben wir es bei JavaScript mit dynamischer sowie schwacher Typisierung zu tun. Wir können Typen zur Laufzeit implizit umwandeln, mit obskuren Ergebnissen9.

Frage: Was wäre die Alternative?

Ed Post: Bei anderen Programmiersprachen kann man sich auf einen Typen verlassen, wenn dieser einmal definiert wurde, und zwar beim Kompilieren und nicht erst beim Kunden zur Laufzeit. Dafür muss man sich zur Übersetzungszeit festlegen. Es wird immer ein “Für und Wider” geben bezüglich dieser Konzepte.

Ein Fazit

Frage: Und welches Fazit würden Sie ziehen?

Ed Post: Das Thread-Modell von JavaScript halte ich bei der aktuellen Prozessor-Entwicklung für anachronistisch. Die Taktfrequenzen können bei CPUs nicht mehr beliebig gesteigert werden, also wird dies bei aktuellen Prozessoren durch Parallelisierung kompensiert. Diese Parallelisierung wird nicht gut bis sehr schlecht von JavaScript unterstützt10.

a) Das Thread-Modell von JavaScript passt nicht mehr zu aktuellen Prozessoren.

Ed Post: Gerade beim Internet der Dinge fehlt mir bei JavaScript die Interoperabilität mit der Hardware, also die gemeinsame effiziente Nutzung von Speicher, was durch fehlende primitive Ganzzahltypen und der ganz eigenen Interpretation des Arrays-Konstrukts befeuert wird11.

b) Das Speicher-Layout von JavaScript erschwert die Interoperabilität auf Low-Level Ebene.

Ed Post: Der saloppe Umgang mit Paketen beim De-facto-Standard npm12 sowie die hohe Zerfallsrate bei JS-Bibliotheken birgt unnötige Sicherheitsrisiken und lässt Softwaresysteme veralten, sobald diese produktiv sind13. Ganz zu schweigen vom Schindluder, das mit npm Paketen getrieben wird13.

c) Der Paketmanager npm birgt ein hohes Risiko was die Aktualität der eigenen Software wie auch das Einbinden von Schadcode in eigenen Anwendungen angeht.

Ed Post: Mit WebAssembly ist eine echte polyglotte Alternative zu JavaScript am Start, und das ohne Unzulänglichkeiten von JavaScript. Mit steigender Verbreitung von WebAssembly wird die Verwendung von JavaScript sinken. JavaScript wird dann wieder für das verwendet werden, für das es ursprünglich konzipiert wurde, also als “‘glue language’ for the Web designers and part time programmers”14.

d) WebAssembly wird wohl JavaScript mittelfristig als einzige Programmiersprache für Browser-Anwendungen abzulösen.

Ed Post: Und einfach bzw. ohne Boilerplate ist die ernsthafte JavaScript-Entwicklung schon lange nicht mehr zu meistern15. JavaScript war ja lange die Lingua franca des Webs.

e) JavaScript hat als Programmiersprache wohl nur deshalb eine gewisse Verbreitung, weil es Bestandteil eines jeden Browsers ist und damit auf jedem Computer verfügbar.

JavaScript war lange Zeit die Lingua franca des Webs […]

… weil Alternativen für Browser-Anwendungen wie WebAssembly gefehlt haben, was sich aber gerade mit viel Schwung ändert.16

Frage: Das spannt den Bogen von unserer anfänglichen Aussage, dass JavaScript die Lingua franca des Webs ist. Haben sie noch ein Schlusswort für unsere Leser?

Ed Post: Zusammenfassend komme ich zu dem Schluss, dass ich für kritische Systeme strikt von JavaScript abrate.

Frage: Vielen Dank für das anregende und erhellende Gespräch! Hoffen wir, dass das ein Weckruf für den einen oder die andere Entwickelnde sein wird! Wollen Sie unseren Lesern noch etwas auf den Weg mitgeben?

Schlusswort von Ed Post

Ed Post : Mit WebAssembly werden endlich performantere und ressourcenschonendere Desktop-Anwendungen (als mit JavaScript realisierbar, Anm.d.Red.) ermöglicht, und das ganze Plattform-Übergreifend: Denn die entsprechenden Browser laufen auf Personalcomputern bis hin zum Raspberry PI sowohl unter Windows wie auch unter MacOS oder Linux, ganz zu schweigen von Android oder iOS auf Smartphones. Irgendwann wird also jemand auf die Idee kommen:

Hey, die WebAssembly VM (Virtual Machine, Anm.d.Red.) kann man doch vorzüglich auch außerhalb des Browsers verwenden!”.

Ed Post … Also wird es WebAssembly-Laufzeitumgebungen ausserhalb des Browsers geben, auf dem Server, auf dem PC, auf dem Einplatinencomputer, im Smartphone oder in der Cloud. Das wird unausweichlich sein. Wenn das passiert, wird das Konzept HTML/CSS/DOM (DOM steht für Dokument Object Model, Anm.d.Red.) nur eine Möglichkeit von vielen sein, um graphische Oberflächen zu bauen …

Die WebAssembly-VM wird aus dem Browser ausbrechen […]

… um als eigenständige VM sowohl Server- wie auch Client-, Desktop-, PC-, Single-board Computer, Smartphone- oder Cloud-Anwendungen zu betreiben, und das bei einer reichhaltingen Auswahl an möglichen Programmiersprachen und deren Ökosystemen.17

Ed Post … Andere GUI-Frameworks, vielleicht sogar bessere, gar andere Ökosysteme, werden adaptiert werden. JavaScript wird zwangsläufig an Bedeutung verlieren und Sprachen wie C++, Python, Java bzw. die .NET basierten Sprachen werden eine (alternative, Anm.d.Red.) VM bekommen. Damit wird das polyglotte Ökosystem schlechthin entstehen. JavaScript wird sich dann wieder auf seine Nische “Glue-Code” im Browser zurückziehen oder nach WebAssembly compilieren. Je mehr WebAssembly an Bedeutung gewinnt, desto mehr wird JavaScript an Bedeutung verlieren.

In Teil 1 dieses Interviews haben wir uns mit den wilden Jahren von JavaScript befasst, in Teil 2 sprachen wir über besondere JavaScript-Spezialitäten und in Teil 3 wagte Ed Post ein Fazit und eine Prognose zu JavaScript.

  1. Siehe Real programmers von Ed Post, 1982  2

  2. Siehe Understanding ES6 Modules von Craig Buckler, 2018 

  3. Siehe Versionsgeschichte von ECMAScript (ECMA-262) auf Wikipedia (de), 2018 

  4. Siehe BigInt: arbitrary-precision integers auf Chrome Platform Status, 2018 

  5. Siehe JavaScript Is Turing Complete— Explained von Raja Rao, 2016 

  6. Siehe Turing completeness auf Wikipedia (en), 2018 

  7. Siehe List of JVM languages von Wikipedia (en), 2018 

  8. Siehe Functional programming auf Wikipedia (en), 2018 

  9. Siehe wtfjs von Brian LeRoux & Andrew Lunny, 2016 

  10. Siehe Concurrency model and the event loop auf MDN, 2018 

  11. Siehe Understanding JavaScript Arrays von Angus Croll, 2010 

  12. Siehe Populäres NPM-Paket verteilt Schadsoftware von Hanno Böck, 2018 

  13. Siehe Longevity (or Lack Thereof) in JavaScript Frameworks von Brian Moschel, 2015  2

  14. Siehe JavaScript: how it all began von Axel Rauschmayer, 2011 

  15. Siehe It’s not Javascript “Tool Fatigue”, it’s Javascript Bullsh*t Fatigue von Anne Dev, 2016 

  16. Siehe WebAssembly support now shipping in all major browsers von Judy McConnell, 2017 

  17. Siehe Ed Post über JavaScript von Ed Post, 2019