JavaScript Engines: Performance-Steigerung der Browser

Seite 3: JavaScript übernimmt Rolle von Java

Inhaltsverzeichnis

JavaScript war also als einfache zugängliche Sprache konzipiert, was zu Lasten der Performance ging. Leider lief die weitere Entwicklung nicht nach Plan. Java überlebte als "Websprache" nicht und JavaScript blieb übrig. Durch die immer stärkere Durchdringung des Internets wurde immer häufiger der Browser statt des Desktops als bevorzugte Plattform für Anwendungen gewählt. JavaScript, als einzige Alternative, kam nun auch für große Anwendungen zum Einsatz. Die Applikationen waren nicht wirklich performant – die Suche nach Antworten im Bereich der Engines begann.

Die Engine führt den Programmcode aus. Somit ist sie fixer Bestandteil jedes Browsers und läuft natürlich auch in Node.js (serverseitig) oder Electron (desktopseitig). Jeder Browserhersteller hat seine eigene Engine. Es sollte keine Überraschung sein, dass ein Browser, der JavaScript schnell ausführt, auch bei den Benutzern vorne liegt. Somit können die Browserentwickler sich mit einer schnellen Engine einen entscheidenden Marktvorteil im heiß umkämpften Browsermarkt verschaffen.

Vier große Hersteller dominieren zurzeit den Markt: Apple (Safari), Google (Chrome), Microsoft (Edge) sowie Mozilla (Firefox). Jeder Hersteller hat seine eigene Engine mit einem "hippen" Namen versehen. Am Bekanntesten ist sicherlich V8, die Engine von Chrome. Die restlichen lauten JavaScriptCore (Safari), Chakra (Edge) sowie SpiderMonkey (Firefox). Microsoft hat allerdings Anfang Dezember bekanntgegeben, künftig auf Chromium, und damit auf Googles V8 Engine umzusteigen. Eine erste Preview ist für Anfang 2019 geplant: Dann wären es nur noch drei.

V8 hat einen besonderen Stellenwert. Sie war nicht nur die erste "zeitgemäße Engine", die JavaScript performancetechnisch auf das benötigte Level brachte, um große Anwendungen performant laufen zu lassen, sondern stellt auch die Standard-Engine in Node.js und Electron dar.

Die verschiedenen Engines funktionieren im Detail sehr unterschiedlich. Nichtsdestotrotz basieren sie auf denselben Prinzipien. Die Engine versucht im Nachhinein die beiden behandelten "Mankos" der Programmiersprache wieder wettzumachen. Sie integriert während der Laufzeit einen Compiler sowie statische Typen beziehungsweise versucht deren Funktionen nachzubilden.

Technisch gesehen, ist ein derartiges Nachrüsten während der Laufzeit eine Herausforderung – vergleichbar mit der Idee, die Software eines Flugzeugs während des Flugs umzuschreiben. Wieso muss das eigentlich die Engine machen? Wieso kann man stattdessen nicht die Änderungen an JavaScript direkt vornehmen?

Statische Typisierung kann nicht funktionieren, wenn die Programmiersprache auf einer dynamischen basiert. Die Sprache im Nachhinein umzustellen macht die meisten Anwendungen inkompatibel. Somit scheidet die Option aus. Selbiges gilt für den Fall, JavaScript zu einer kompilierten Sprache umzufunktionieren. Man müsste schon eher eine neue Programmiersprache von Grund auf neu konzipieren: WebAssembly lässt grüßen