What New JavaScript Proposals Emerged from TC39’s 2020 Meeting?

TC39’s final 2020 meeting did not advance any proposals from Stage 2 to Stage 3 or from Stage 3 to Stage 4.

Stage 1 → Stage 2

Advancing from Stage 1 to Stage 2 requires a complete draft specification covering all aspects of the proposal.

Proposal link: https://github.com/tc39/proposal-error-cause

Proposal text: https://tc39.es/proposal-error-cause/

The Error Cause proposal adds an optional cause parameter to the Error constructor, accepting any JavaScript value and assigning it to the cause property.

This feature mirrors similar designs in C#, Java, and Python, and is already widely used in the JavaScript ecosystem (e.g., verror, @netflix/nerror). It enables developer tools like Chrome DevTools to display the cause value by default, improving exception handling.

try {
  return await fetch('//unintelligible-url-a')
    .catch(err => {
      throw new Error('Download raw resource failed', err)
    })
} catch (err) {
  console.log(err)
  console.log('Caused by', err.cause)
  // Error: Upload job result failed
  // Caused by TypeError: Failed to fetch
}

Stage 0 → Stage 1

Advancing from Stage 0 to Stage 1 requires:

Finding a TC39 champion for the proposal.

Clearly defining the problem, need, and a rough solution.

Providing examples of the problem and solution.

Discussing API shape, key algorithms, semantics, and implementation risks.

Example proposal: JavaScript Module Blocks (https://github.com/tc39/proposal-js-module-blocks)

Many devices now have multiple cores, and JavaScript can run in several execution units (workers, Node.js processes, etc.). Existing approaches for sharing code across units are inefficient or insecure.

let workerCode = module {
  onmessage = function({ data }) {
    let mod = await import(data);
    postMessage(mod.fn());
  };
};
let worker = new Worker(workerCode, { type: 'module' });
worker.onmessage = ({ data }) => alert(data);
worker.postMessage(module { export function fn() { return 'hello!' } });

Previous related proposal: Blöck, now revived by a new committee.

Extensions

Proposal link: https://github.com/hax/proposal-extensions

The Extensions proposal reintroduces ideas from the Bind Operator, adding local‑scope extensions, accessor syntax, and a dedicated namespace to avoid clashes with ordinary variables.

// Define a toSet method for collection types
const ::toSet = function () { return new Set(this) }

// Add an accessor for all divs in a DOM object
const ::allDivs = function { get() { return this.querySelectorAll('div') } }

const ::flatMap = Array.prototype.flatMap
const ::size = Object.getOwnPropertyDescriptor(Set.prototype, 'size')

let classCount = document
  ::allDivs
  ::flatMap(element => element.classList)
  ::toSet()
  ::size

Key differences from the Bind Operator include a new field‑accessor definition, independent namespace for local extensions, and the :: operator sharing precedence with .. The BindExpression syntax ( ::obj.foo) is removed.

Grouped Accessor

Proposal link: https://github.com/rbuckton/proposal-grouped-and-auto-accessors

This Microsoft‑backed proposal allows getters and setters to be declared together, facilitating more ergonomic decorator usage.

class C {
  x {
    get() { /* ... */ }
    set(value) { /* ... */ }
  }
}

const obj = {
  x {
    get() { /* ... */ }
    set(value) { /* ... */ }
  }
}

class D {
  @logger()
  x {
    get() { /* ... */ }
    set(value) { /* ... */ }
  }
}

The proposal sparked extensive discussion and only entered Stage 1 after many debates.

Summary

The meeting highlighted the rigorous stage‑gate process that forces proposal authors to articulate problems, solutions, and implementation considerations, ensuring ECMAScript evolves in a controlled, well‑justified manner.