ECMAScript 2026 guide: the 7 new JavaScript features and where each one runs today

What shipped in ECMAScript 2026, and what can you use today?#

ECMAScript 2026 added 7 features, and MDN compatibility data in October 2026 shows Node.js 24 LTS runs 3 of them without a polyfill. The edition is a set of small additions to the standard library, with no new syntax. So a team can adopt it one method at a time.

Ecma International's page for the standard says it "defines the ECMAScript 2026 general-purpose programming language" in its 17th edition. Meanwhile, the TC39 finished proposals table is the record of what each edition holds. In its own words, "Finished proposals are proposals that have reached stage 4", and each row carries an expected publication year.

So the 7 ECMAScript 2026 JavaScript features, the rows with 2026 in that column, are short to list:

• Array.fromAsync, which builds an array from an async iterable.
• JSON.rawJSON and source text access in the JSON.parse reviver.
• Error.isError, a reliable test for a real error object.
• Uint8Array.fromBase64 and its siblings for base64 and hex.
• Map.prototype.getOrInsert and getOrInsertComputed, also on WeakMap.
• Iterator.concat, which chains iterables in sequence.
• Math.sumPrecise, which adds numbers without rounding on the way.

However, an edition year says nothing about where the code runs. Support for these 7 arrived over a long run of releases, from JSON.rawJSON in Chrome 114, to Iterator.concat in Safari 26.4, in MDN browser-compat-data read on 7 October 2026. Each runtime picked them up in its own order. So the useful question is never "is ES2026 ready". Instead, ask which of the 7 your oldest runtime already runs.

What does ECMAScript 2026 remove from a JavaScript codebase?#

Each ES2026 feature retires a helper teams already maintain: a base64 package, an upsert wrapper, a precise-sum loop or a cross-realm error check. So deleted code is the value, and it only pays off once every runtime you ship to runs the feature natively.

Take grouping first. For instance, most codebases hold a line like if (!map.has(key)) map.set(key, []) before a push. Then getOrInsert turns that into one call that returns the existing value or stores the default. MDN's page also points to getOrInsertComputed for a default that is costly to build. Its callback runs only when the key is missing.

Second, there is base64. MDN's fromBase64 page, read on 7 October 2026, says "This method should be preferred over Window.atob()". MDN gives the reason: it "results in a byte array, which is easier to work with than a string containing raw bytes". Uint8Array.fromBase64 returns bytes directly and accepts the URL-safe alphabet through an option.

Third, there are sums. MDN's Math.sumPrecise page says the method "avoids floating point precision loss in intermediate results". For example, MDN shows a plain loop over 1e20, 0.1 and -1e20 returning 0, while Math.sumPrecise returns 0.1. Also, teams that total money or sensor readings often carry a compensated-sum helper for exactly this.

Finally, Error.isError replaces instanceof Error checks that fail across realms. As MDN explains, instanceof returns false for an error built in another realm, such as an iframe. In practice, the saving is small per feature but adds up across a codebase. A team can delete one dependency, one wrapper and two hand-written helpers. Still, each deletion has to wait until the oldest runtime catches up.

Which features are in the 2026 edition, and which lists get it wrong?#

The TC39 finished-proposals table, read on 7 October 2026, lists 7 proposals for 2026 and moves Temporal and explicit resource management to 2027. In short, that column is the only test that matters. An ES2026 feature is one whose expected publication year is 2026, whatever a summary calls it.

The mislabels come in two kinds. First, some lists still file Iterator helpers or Float16Array under 2026, although the same table puts them in the 2025 edition. Second, many lists add Temporal and the using keyword to 2026 because both were widely discussed that year. However, the table gives both an expected publication year of 2027, so neither is part of the 2026 standard.

Meanwhile, the 2027 queue is already full. The TC39 table read on 7 October 2026 gives that year to seven of them: iterator chunking, Iterator Includes, Iterator Join, explicit resource management, Atomics.pause, joint iteration and Temporal. This matters for planning, since some runtimes ship 2027 features before 2026 ones. Therefore, a version number never tells you which edition a runtime has finished.

Which browsers and runtimes support each ES2026 feature today?#

MDN browser-compat-data, read on 7 October 2026, shows Array.fromAsync shipped first, in Chrome 121, and Iterator.concat arrived last among the browsers, in Safari 26.4. That is, Array.fromAsync was the first to be complete across all three browser engines. JSON.rawJSON reached Chrome earlier, but Firefox only in version 135, in the same October 2026 data. As a result, one feature can be safe on your floor while its neighbour in the same edition is not.

In practice, every verdict in this ECMAScript 2026 guide reads from that table, and it splits into three groups. First, Array.fromAsync, JSON.rawJSON and Error.isError run in all three browser engines and in recent Node.js. Second, the base64 methods run in Chrome 140, Firefox 133 and Safari 18.2 in MDN browser-compat-data read on 7 October 2026, but Node.js waits until 25.0.0. Third, getOrInsert, Iterator.concat and Math.sumPrecise need 2026 browser releases, and Math.sumPrecise has no Node.js version in the data at all.

However, Deno and Bun move faster than Node.js. In the MDN data read on 7 October 2026, Deno runs all 7 features from version 2.7.8. Bun runs all 7 from version 1.3.7. Bun's own documentation says it is "powered by JavaScriptCore", the engine behind Safari. So Bun often gains a feature on a different schedule from Node.js, which uses V8.

Also, ECMAScript 2026 browser support is not server support. Chrome and Node.js share Google's V8 engine, yet MDN browser-compat-data, read on 7 October 2026, shows Error.isError in Chrome 134, but in Node.js only from 24.3.0. So a feature can reach Chrome long before an LTS line carries it.

What should a codebase on Node.js 22 or 24 LTS do with ES2026?#

Node.js 24 LTS runs 3 of the 7 features and Node.js 22 LTS runs 2, per MDN compatibility data read on 7 October 2026. That count for Node.js 24 starts at release 24.3.0. Because most servers sit on an LTS line, the gap is wide. The Node.js releases page is plain about it: "Production applications should only use Active LTS or Maintenance LTS releases".

On an LTS line, the edition splits into three verdicts, and the line's version decides each one. For Node.js 22, adopt Array.fromAsync and JSON.rawJSON now. Then, on Node.js 24, add Error.isError once you run 24.3.0 or later. Everything else is a polyfill or a wait, at least for now.

For example, say your lowest targets are Node.js 24 LTS on the server and Safari 18.4 in the browser. In the MDN data read on 7 October 2026, both run Array.fromAsync, JSON.rawJSON and Error.isError, so those 3 are safe to adopt. The base64 methods run in Safari 18.4 but need Node.js 25.0.0. Meanwhile, the same October 2026 data puts getOrInsert and Iterator.concat at Node.js 26.0.0, plus Safari 26.2 and Safari 26.4 respectively. Finally, Math.sumPrecise has no Node.js release in that data. So 4 of the 7 are polyfill-or-wait for this team.

However, Node.js 26 changes the picture. The releases page lists it as Current on 7 October 2026, and MDN compatibility data shows it runs 6 of the 7. Also, the same page says that from Node.js 27, "every major version will move to LTS status". That shortens the wait for the next edition.

What does Baseline newly available mean before you ship to browsers?#

MDN marks Map.prototype.getOrInsert, Iterator.concat and Math.sumPrecise as Baseline 2026 newly available, which means current browsers only, not older devices. That label is easy to misread as safe on every device in use. In fact, it means the latest version of each core browser runs the feature.

The MDN Baseline glossary, read on 7 October 2026, opens with a clear line: "Baseline is a summary of browser support". Then it defines two states. Newly available features "work in at least the latest stable version of each of the Baseline browsers, but may not work with older browsers and devices". In the same glossary, widely available features have "a consistent history of support" for at least 2.5 years.

So, as a rule of this ECMAScript 2026 guide, map the label onto your own support policy. For example, say a site supports the last two Safari releases. It can treat a newly available feature as safe only once both carry it. On the other hand, a site with many users on older iPhones should wait for widely available, or ship a fallback.

In MDN's pages read on 7 October 2026, Array.fromAsync is already widely available. By contrast, Error.isError still shows limited availability on its MDN page, so check the compat table rather than the badge. JSON.rawJSON and the base64 methods are Baseline 2025, while the other three are Baseline 2026.

Which documentation pages should you build from?#

Four documentation pages cover adoption in build order: MDN compatibility data for the floor, the MDN method pages, then the core-js README for polyfills. Open them in this order, and take one thing from each.

1. MDN browser-compat-data for Map: the version_added value per runtime, which is your floor check.
2. The Map.prototype.getOrInsert reference on MDN: the getOrInsert(key, defaultValue) signature and when to use getOrInsertComputed.
3. The Uint8Array.fromBase64 reference: the alphabet and lastChunkHandling options.
4. core-js README: the entry point for each polyfill, such as core-js/proposals/map-upsert-v4 and core-js/proposals/math-sum.

1. Check the floor

   MDN browser-compat-data for Map: the version_added value per runtime.

2. Read the signature

   The Map.prototype.getOrInsert reference on MDN: getOrInsert(key, defaultValue), and when to use getOrInsertComputed.

3. Read the options

   The Uint8Array.fromBase64 reference: the alphabet and lastChunkHandling options.

4. Pick the polyfill

   core-js README: the entry point for each polyfill, such as core-js/proposals/map-upsert-v4 and core-js/proposals/math-sum.

Also, the same compat files exist for every feature. Swap Map.json for Math.json or Iterator.json as needed. Then read the MDN page for exact behaviour, because a polyfill copies the standard, not your old helper.

What is the smallest safe way to start using ES2026 features?#

Feature-detect each method at startup, use it when present, and load a single core-js entry point only for the features your floor lacks. That keeps the native path on new runtimes and costs nothing extra on them.

The file below is CommonJS because the core-js README lists these as CommonJS entry points. Save it as start.cjs, run npm install core-js, then run node start.cjs.

// 1. Load a polyfill only where the runtime lacks the method.
if (typeof Map.prototype.getOrInsert !== "function") {
  require("core-js/proposals/map-upsert-v4");
}
if (typeof Math.sumPrecise !== "function") {
  require("core-js/proposals/math-sum");
}

// 2. Group values without a has-then-set wrapper.
const orders = [
  { id: 1, status: "paid" },
  { id: 2, status: "open" },
  { id: 3, status: "paid" },
];
const byStatus = new Map();
for (const order of orders) {
  byStatus.getOrInsert(order.status, []).push(order.id);
}
console.log(byStatus); // Map(2) { 'paid' => [ 1, 3 ], 'open' => [ 2 ] }

// 3. Decode base64 to bytes, with Buffer as the Node.js fallback.
const bytes =
  typeof Uint8Array.fromBase64 === "function"
    ? Uint8Array.fromBase64("SGVsbG8=")
    : new Uint8Array(Buffer.from("SGVsbG8=", "base64"));
console.log(new TextDecoder().decode(bytes)); // Hello

// 4. Sum without losing precision on the way.
console.log(Math.sumPrecise([1e20, 0.1, -1e20])); // 0.1

Each check runs once at startup, so the cost is negligible. Later, when your floor runs a feature natively, delete its require block. On Node.js 26, that already covers getOrInsert and the base64 fallback branch. The calls stay the same because they were written against the standard from the start.

When is a polyfill the wrong tool for ES2026 features?#

A polyfill is the wrong fit for Error.isError, because core-js itself says it has no bulletproof way to check whether an object is an error. Where a feature cannot be copied faithfully, keeping the existing helper is the better choice.

The core-js README is candid: "We have no bulletproof way to polyfill this", and it calls its version "an enough naive implementation". Therefore, on a runtime below Node.js 24.3.0, keep your current error check. A naive polyfill that answers wrongly is worse than a known instanceof test.

Second, skip a polyfill when native support is nowhere in sight on your floor. For instance, Math.sumPrecise has no Node.js release in the MDN data read on 7 October 2026. In that case, a small, well-tested compensated-sum function you already own is the better tool. You control its exact behaviour.

Third, skip ES2026 for code that runs on an engine outside MDN's compat data, such as an embedded or locked-down engine. With no record to check against, a feature check is a guess. Instead, stick to the subset your engine's own documentation lists. In short, a polyfill earns its place only when it is faithful and the gap is short.

What does this ECMAScript 2026 guide leave for 2027?#

The TC39 table already lists 7 finished proposals for 2027, Temporal and explicit resource management among them, so the same floor check applies next year. That count comes from the TC39 table as read on 7 October 2026, and the method repeats every edition. Read the TC39 record, read the compat data for your oldest runtime, then adopt, polyfill or wait.

First, Temporal brings a modern date and time API, and explicit resource management brings the using keyword. Neither belongs in a 2026 support policy. However, both are worth tracking, because core-js already ships the explicit resource management built-ins. Its README notes that using syntax still needs transpiler support.

For the rest of the JavaScript you write today, a few routes are worth a look. For example, the clean code practices for JavaScript weigh short built-in forms, such as a Set dedupe, against older helper code. These methods make the same trade. The same post covers the lint rules where a team records which ES2026 methods its targets allow. Also, the Node.js HTTP/2 server walkthrough shows a server where the LTS line decides which of these features run.

When a codebase needs hands for the upgrade, see how to hire JavaScript developers. For runtime upgrades over time, read about ongoing maintenance and support. Still, the TC39 table and the MDN compat files are enough on their own to make every call in this guide.