(This blog post is based on a tweet thread and additional input by Mathias Bynens.)

After work started on it in August 2017, May 2022 finally saw the publication of RFC 9239 “Updates to ECMAScript media types” by Matthew A. Miller, Myles Borins, Mathias Bynens, and Bradley Farias. It updates JavaScript MIME type registrations to align with reality:

• The JavaScript MIME type is now unambiguously text/javascript.
• .mjs is now a registered filename extension, specifically for JavaScript modules.

This unblocks tooling and server software like Apache to support JavaScript modules out of the box in a unified manner, like e.g. Node.js already does. Better industry alignment on MIME type and file extensions increases interoperability across tooling and other software.

In JavaScript, the same syntax – triple dots (...) – is used for two different mechanisms:

• Rest syntax is for receiving data.
• Spreading is for sending data.

This blog post examines how these mechanisms work and why they are not operators.

This blog post describes the ECMAScript proposal “Change Array by copy” by Robin Ricard and Ashley Claymore. It proposes four new methods for Arrays and Typed Arrays:

• .toReversed()
• .toSorted()
• .toSpliced()
• .with()

This blog post describes the ECMAScript proposal “ShadowRealm API” by Dave Herman, Caridy Patiño, Mark S. Miller, Leo Balter, and Rick Waldron.

Class ShadowRealm provides a new way of evaluating code at runtime – think eval() but better:

• Each instance has its own global JavaScript scope.
• Code is evaluated in that scope. If it changes global data, that only affects the ShadowRealm, but not the real global data.

This blog post describes the ECMAScript proposal “Array find from last” by Wenlu Wang and Daniel Rosenwasser.

The ECMAScript proposal “Types as comments” (by Gil Tayar, Daniel Rosenwasser, Romulo Cintra, Rob Palmer, and others) is about adding type annotations to JavaScript (there is also an accompanying blog post).

Such type annotations would look similar to TypeScript’s and Flow’s annotations and are completely ignored at runtime.

In this blog post, I briefly explain how the proposed type annotations would work and then describe what I think about them.

Sometimes the name of a proposed feature (a method, a global variable, etc.) clashes with existing code and has to be changed. This blog post explains how that can happen and lists features that were renamed.

JavaScript has two kinds of values:

• primitive values (undefined, null, booleans, numbers, bigints, strings, symbols)
• objects (all other values)

The ECMAScript specification states:

A primitive value is a datum that is represented directly at the lowest level of the language implementation.

However, despite this fact, we can still use primitive values (other than undefined and null) as if they were immutable objects:

> 'xy'.length
2

This blog post answers the following question:

How do primitive values get their properties?

We’ll look at:

• Getting property values
• Invoking property values (a.k.a. method calls)
• Setting property values

Each time, we’ll first examine what’s going on via JavaScript code and then investigate how the language specification explains the phenomena.

Note that JavaScript engines only mimick the external behavior of the language specification. Some of what the spec does internally is not very efficient (e.g. wrapping primitive values) and often done differently in engines.

Each of the primitive types boolean, number, bigint, string and symbol has an associated wrapper class (Boolean, Number, BigInt, String, Symbol). In this blog post, we examine what these classes are good for.

The proposal “Pipe operator (|>) for JavaScript” (by J. S. Choi, James DiGioia, Ron Buckton and Tab Atkins) introduces a new operator. This operator is an idea borrowed from functional programming that makes applying functions more convenient in many cases.

This blog post describes how the pipe operator works and what its use cases are (there are more than you might expect!).