16 posts tagged with "ECMAScript"

All episodes

Meanwhile in other parts of the Web​

Jason Orendorff from Mozilla published a great in-depth analysis of JS syntactic quirks. Even though the implementation details differ, every JS engine faces the same problems with these quirks.

All episodes

In this episode, we’ll go deeper in the definition of the ECMAScript language and its syntax. If you’re not familiar with context-free grammars, now is a good time to check out the basics, since the spec uses context-free grammars to define the language. See the chapter about context free grammars in "Crafting Interpreters" for an approachable introduction or the Wikipedia page for a more mathematical definition.

Let’s practice our awesome spec reading skills some more. If you haven’t had a look at the previous episode, now it’s a good time to do so!

All episodes

Ready for part 2?​

A fun way to get to know the spec is to start with a JavaScript feature we know is there, and find out how it’s specified.

Warning! This episode contains copy-pasted algorithms from the ECMAScript spec as of February 2020. They’ll eventually be out of date.

We know that properties are looked up in the prototype chain: if an object doesn’t have the property we’re trying to read, we walk up the prototype chain until we find it (or find an object which no longer has a prototype).

For example:

const o1 = { foo: 99 };
const o2 = {};
Object.setPrototypeOf(o2, o1);
o2.foo;
// → 99

Where’s the prototype walk defined?​

Let’s try to find out where this behavior is defined. A good place to start is a list of Object Internal Methods.

There’s both [[GetOwnProperty]] and [[Get]] — we’re interested in the version that isn’t restricted to own properties, so we’ll go with [[Get]].

Unfortunately, the Property Descriptor specification type also has a field called [[Get]], so while browsing the spec for [[Get]], we need to carefully distinguish between the two independent usages.

Why is o2.foo an AssignmentExpression?​

o2.foo doesn’t look like an AssignmentExpression since there’s no assignment. Why is it an AssignmentExpression?

The spec actually allows an AssignmentExpression both as an argument and as the right hand side of an assignment. For example:

function simple(a) {
  console.log('The argument was ' + a);
}
simple(x = 1);
// → Logs “The argument was 1”.
x;
// → 1

…and…

x = y = 5;
x; // 5
y; // 5

o2.foo is an AssignmentExpression which doesn't assign anything. This follows from the following grammar productions, each one taking the "simplest" case until the last one:

An AssignmentExpresssion doesn't need to have an assignment, it can also be just a ConditionalExpression:

AssignmentExpression : ConditionalExpression

(There are other productions too, here we show only the relevant one.)

A ConditionalExpression doesn't need to have a conditional (a == b ? c : d), it can also be just a ShortcircuitExpression:

ConditionalExpression : ShortCircuitExpression

And so on:

ShortCircuitExpression : LogicalORExpression

LogicalORExpression : LogicalANDExpression

LogicalANDExpression : BitwiseORExpression

BitwiseORExpression : BitwiseXORExpression

BitwiseXORExpression : BitwiseANDExpression

BitwiseANDExpression : EqualityExpression

EqualityExpression : RelationalExpression

RelationalExpression : ShiftExpression

All episodes

In this article, we take a simple function in the spec and try to understand the notation. Let’s go!

Preface​

Even if you know JavaScript, reading its language specification, ECMAScript Language specification, or the ECMAScript spec for short, can be pretty daunting. At least that’s how I felt when I started reading it for the first time.

The ECMAScript Internationalization API Specification (ECMA-402, or Intl) provides key locale-specific functionality such as date formatting, number formatting, plural form selection, and collation. The Chrome V8 and Google Internationalization teams have been collaborating on adding features to V8’s ECMA-402 implementation, while cleaning up technical debt and improving performance and interoperability with other browsers.

During his three-months internship on the V8 team, Hai Dang worked on improving the performance of [...array], [...string], [...set], [...map.keys()], and [...map.values()] (when the spread elements are at the start of the array literal). He even made Array.from(iterable) much faster as well. This article explains some of the gory details of his changes, which are included in V8 starting with v7.2.

Asynchronous processing in JavaScript traditionally had a reputation for not being particularly fast. To make matters worse, debugging live JavaScript applications — in particular Node.js servers — is no easy task, especially when it comes to async programming. Luckily the times, they are a-changin’. This article explores how we optimized async functions and promises in V8 (and to some extent in other JavaScript engines as well), and describes how we improved the debugging experience for async code.

Array.prototype.sort was among the last builtins implemented in self-hosted JavaScript in V8. Porting it offered us the opportunity to experiment with different algorithms and implementation strategies and finally make it stable in V8 v7.0 / Chrome 70.

DataViews are one of the two possible ways to do low-level memory accesses in JavaScript, the other one being TypedArrays. Up until now, DataViews were much less optimized than TypedArrays in V8, resulting in lower performance on tasks such as graphics-intensive workloads or when decoding/encoding binary data. The reasons for this have been mostly historical choices, like the fact that asm.js chose TypedArrays instead of DataViews, and so engines were incentivized to focus on performance of TypedArrays.