ECMAScript 2026 and the TC39 Standardisation Process

JavaScript has shipped a new edition of its standard every June since ES2015. The annual date is fixed; what varies is which proposals have reached stage 4 in time to be included. Understanding the TC39 stage process explains why features appear in browsers long before they appear in a numbered edition, and why the edition number is a poor guide to what you can actually use. This article walks through the process and how to decide when a feature is safe to adopt.

An edition every June

ECMA-262, the specification behind JavaScript, is approved by the Ecma General Assembly each June. The edition is named for its year: ES2023, ES2024, ES2025, ES2026.

The release train model was adopted after ES2015, which took six years and grew enormous. The lesson was the same one Java and other platforms drew around the same time: a fixed date with variable content beats a fixed scope with a variable date.

The practical consequence is that the size of an edition varies considerably. Some years bring a long list, others only a handful of small additions. Neither says much about the health of the language.

The stage process

Every feature moves through five stages inside TC39, the committee that maintains the standard.

A proposal reaching stage 4 before the committee’s spring cut-off appears in that year’s edition. Missing it simply means waiting for the next.

Why the edition number misleads

Browsers do not wait for stage 4. Implementations usually start at stage 3, which is the whole point of that stage - implementer feedback is how design problems get found.

So a feature can be shipping in every major browser a year before it formally appears in an edition. By the time ES2026 is approved, most of its contents will already be in production use.

This is why the practical question is never “which edition is this in” but “what is the support matrix”. A compatibility table is more useful than a specification date.

Recent additions

Features that reached stage 4 in recent cycles illustrate the direction of travel:

• Iterator helpers, bringing map, filter, take and drop to iterators without materialising arrays.
• Set methods such as union, intersection and difference.
• Promise.try, for starting a promise chain from a function that might throw synchronously.
• RegExp.escape, for safely embedding a string in a pattern.
• Import attributes and JSON modules, standardising how non-JavaScript resources are imported.
• Explicit resource management with using declarations, giving deterministic cleanup.

const firstTen = someInfiniteIterator()
  .filter(x => x % 2 === 0)
  .map(x => x * x)
  .take(10)
  .toArray();

Longer-running proposals such as Temporal, the replacement for the Date API, and decorators have spent extended periods at stage 3 precisely because implementation surfaces problems that need resolving before they are locked in.

Adopting features safely

• Check the support matrix, not the edition. Compatibility tables reflect reality; edition numbers reflect committee process.
• Know your transpilation target. Build tools let you write modern syntax and emit older output, but new built-in methods need polyfills rather than syntax transforms.
• Be cautious with stage 3. It is stable enough to experiment with and unstable enough to change. Using it in a library that others depend on is riskier than using it in an application you control.
• Watch Node.js as well as browsers. Server-side support arrives with V8 upgrades in each Node major, which is a different schedule from the browser release trains.

Conclusion

ECMAScript’s annual June edition is a snapshot of what finished, not an announcement of what is newly available. The stage process is the real timeline: proposals become implementable at stage 3, ship in engines soon after, and are formally recorded at stage 4 in the following edition. Track the stages and the support matrix, and treat the edition number as a historical label.