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

Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s Git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 8.1, which is in beta until its release in coordination with Chrome 81 Stable in several weeks. V8 v8.1 is filled with all sorts of developer-facing goodies. This post provides a preview of some of the highlights in anticipation of the release.

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.

It’s finally here. Every V8 release, every six weeks when we branch as part of our release process, the question comes up about what will happen when V8 hits version 8. Will we have a party? Will we ship a new compiler? Will we skip versions 8 and 9 and just stay at an eternal V8 version X? Finally, after over 10 years of work, on our 100th blog post, we’re pleased to announce our newest branch, V8 version 8.0 V8, and we can finally answer that question:

Emscripten has always focused first and foremost on compiling to the Web and other JavaScript environments like Node.js. But as WebAssembly starts to be used without JavaScript, new use cases are appearing, and so we've been working on support for emitting standalone Wasm files from Emscripten, that do not depend on the Emscripten JS runtime! This post explains why that's interesting.

Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s Git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 7.9, which is in beta until its release in coordination with Chrome 79 Stable in several weeks. V8 v7.9 is filled with all sorts of developer-facing goodies. This post provides a preview of some of the highlights in anticipation of the release.

In its default configuration, V8 compiles regular expressions to native code upon the first execution. As part of our work on JIT-less V8, we introduced an interpreter for regular expressions. Interpreting regular expressions has the advantage of using less memory, but it comes with a performance penalty. In this blog post we describe how we take advantage of the upsides of interpreting regular expressions while mitigating the downsides.

Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s Git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 7.8, which is in beta until its release in coordination with Chrome 78 Stable in several weeks. V8 v7.8 is filled with all sorts of developer-facing goodies. This post provides a preview of some of the highlights in anticipation of the release.

In late 2018 we started a project called V8 Lite, aimed at dramatically reducing V8’s memory usage. Initially this project was envisioned as a separate Lite mode of V8 specifically aimed at low-memory mobile devices or embedder use-cases that care more about reduced memory usage than throughput execution speed. However, in the process of this work, we realized that many of the memory optimizations we had made for this Lite mode could be brought over to regular V8 thereby benefiting all users of V8.

Previously, we discussed how JavaScript engines optimize object and array access through the use of Shapes and Inline Caches, and we’ve explored how engines speed up prototype property access in particular. This article describes how V8 chooses optimal in-memory representations for various JavaScript values, and how that impacts the shape machinery — all of which helps explain a recent V8 performance cliff in React core.