Jason Orendorff von Mozilla veröffentlichte eine großartige tiefgehende Analyse von JS-syntaktischen Eigenheiten. Auch wenn sich die Implementierungsdetails unterscheiden, sieht sich jede JS-Engine denselben Problemen mit diesen Eigenheiten gegenüber.
In dieser Episode vertiefen wir uns in die Definition der ECMAScript-Sprache und ihrer Syntax. Falls Sie mit kontextfreien Grammatiken nicht vertraut sind, ist jetzt ein guter Zeitpunkt, die Grundlagen zu überprüfen, da die Spezifikation kontextfreie Grammatiken zur Definition der Sprache verwendet. Sehen Sie das Kapitel über kontextfreie Grammatiken in "Crafting Interpreters" für eine zugängliche Einführung oder die Wikipedia-Seite für eine mathematischere Definition.
Lass uns unsere fantastischen Fähigkeiten im Lesen der Spezifikation weiter üben. Falls du dir die vorherige Folge noch nicht angeschaut hast, ist jetzt ein guter Zeitpunkt dafür!
Eine unterhaltsame Möglichkeit, die Spezifikation kennenzulernen, besteht darin, mit einer JavaScript-Funktion zu beginnen, von der wir wissen, dass sie existiert, und herauszufinden, wie sie spezifiziert ist.
Warnung! Diese Folge enthält kopierte Algorithmen aus der ECMAScript-Spezifikation von Februar 2020. Sie werden irgendwann veraltet sein.
Wir wissen, dass Eigenschaften in der Prototypenkette nachgeschlagen werden: Wenn ein Objekt die Eigenschaft, die wir lesen möchten, nicht hat, gehen wir die Prototypenkette hinauf, bis wir sie finden (oder ein Objekt finden, das keinen Prototyp mehr hat).
Zum Beispiel:
const o1 = { foo: 99 };
const o2 = {};
Object.setPrototypeOf(o2, o1);
o2.foo;
// → 99
Lass uns versuchen herauszufinden, wo dieses Verhalten definiert ist. Ein guter Ausgangspunkt ist eine Liste von Internen Methoden von Objekten.
Es gibt sowohl [[GetOwnProperty]] als auch [[Get]] — wir sind an der Version interessiert, die sich nicht nur auf eigene Eigenschaften beschränkt, also entscheiden wir uns für [[Get]].
Leider hat der Spezifikationstyp Property Descriptor ebenfalls ein Feld namens [[Get]], daher müssen wir beim Durchblättern der Spezifikation für [[Get]] sorgfältig zwischen den beiden unabhängigen Verwendungen unterscheiden.
o2.foo ein AssignmentExpression?o2.foo sieht nicht wie eine AssignmentExpression aus, da es keine Zuweisung gibt. Warum ist es trotzdem eine AssignmentExpression?
Die Spezifikation erlaubt tatsächlich eine AssignmentExpression sowohl als Argument als auch auf der rechten Seite einer Zuweisung. Zum Beispiel:
function simple(a) {
console.log('Das Argument war ' + a);
}
simple(x = 1);
// → Gibt „Das Argument war 1“ aus.
x;
// → 1
…und…
x = y = 5;
x; // 5
y; // 5
o2.foo ist eine AssignmentExpression, die nichts zuweist. Dies ergibt sich aus den folgenden Produktionsregeln der Grammatik, jede nimmt den "einfachsten" Fall bis zur letzten:
Eine AssignmentExpression muss keine Zuweisung enthalten, sie kann auch einfach eine ConditionalExpression sein:
(Es gibt auch andere Produktionsregeln, aber hier zeigen wir nur die relevante.)
Eine ConditionalExpression muss keine Bedingung (a == b ? c : d) enthalten, sie kann auch einfach eine ShortcircuitExpression sein:
Und so weiter:
ShortCircuitExpression : LogicalORExpression
LogicalORExpression : LogicalANDExpression
LogicalANDExpression : BitwiseORExpression
BitwiseORExpression : BitwiseXORExpression
BitwiseXORExpression : BitwiseANDExpression
BitwiseANDExpression : EqualityExpression
In diesem Artikel nehmen wir eine einfache Funktion in der Spezifikation und versuchen, die Notation zu verstehen. Los geht's!
Auch wenn Sie JavaScript kennen, kann das Lesen der Sprachspezifikation, der ECMAScript-Sprachspezifikation, kurz ECMAScript-Spezifikation, ziemlich einschüchternd sein. Zumindest so habe ich mich gefühlt, als ich sie das erste Mal gelesen habe.
Die ECMAScript Internationalization API-Spezifikation (ECMA-402, oder Intl) bietet wichtige lokalisierungsspezifische Funktionen wie Datumsformatierung, Zahlenformatierung, Pluralformauswahl und Sortierung. Die Chrome-V8- und Google-Internationalisierungsteams haben an der Erweiterung der Funktionen der ECMA-402-Implementierung von V8 gearbeitet, während sie technischen Schulden abbauen und die Leistung sowie die Interoperabilität mit anderen Browsern verbessern.
Während seines dreimonatigen Praktikums im V8-Team arbeitete Hai Dang daran, die Leistung von [...array], [...string], [...set], [...map.keys()] und [...map.values()] zu verbessern (wenn die Spread-Elemente am Anfang des Array-Literals stehen). Er machte auch Array.from(iterable) deutlich schneller. Dieser Artikel erklärt einige Details seiner Änderungen, die ab V8 v7.2 enthalten sind.
Asynchrone Verarbeitung in JavaScript hatte traditionell den Ruf, nicht besonders schnell zu sein. Noch schlimmer war es, Live-JavaScript-Anwendungen – insbesondere Node.js-Server – zu debuggen, besonders wenn es um asynchrone Programmierung geht. Glücklicherweise ändern sich die Zeiten. Dieser Artikel untersucht, wie wir asynchrone Funktionen und Versprechen in V8 (und teilweise auch in anderen JavaScript-Engines) optimiert haben und beschreibt, wie wir die Debugging-Erfahrung für asynchronen Code verbessert haben.
Array.prototype.sort gehörte zu den letzten eingebauten Funktionen, die in selbst gehostetem JavaScript in V8 implementiert wurden. Die Portierung bot uns die Möglichkeit, mit verschiedenen Algorithmen und Implementierungsstrategien zu experimentieren und sie schließlich stabil zu machen in V8 v7.0 / Chrome 70.
DataViews sind eine der zwei möglichen Methoden, um Speicher auf niedriger Ebene in JavaScript zuzugreifen, die andere ist TypedArrays. Bislang waren DataViews in V8 viel weniger optimiert als TypedArrays, was zu einer schlechteren Leistung bei Aufgaben wie grafikintensiven Workloads oder beim Decodieren/Kodieren von Binärdaten führte. Die Gründe dafür waren hauptsächlich historische Entscheidungen, wie die Tatsache, dass asm.js TypedArrays statt DataViews gewählt hat, und so waren Engines motiviert, sich auf die Leistung von TypedArrays zu konzentrieren.