Modern JavaScript, ES2023 to ES2026

Two questions for every new feature

A feature has a spec year and a support date, and they are different things. ES2025 means the committee finalised it in 2025; whether your users' browsers run it is a separate question. So for any feature there are two checks: is it in the language, and is it Baseline — working in the current version of every major browser — for the audience you have? "Newly available" Baseline means it just crossed that line; "widely available" means it has held for about two and a half years.

Treat this table as a starting point, not a source of truth: support changes every few weeks. The pages that stay current are MDN (each page ends with a compatibility table) and the Baseline badges on MDN and web.dev.

Iterator helpers: lazy chains without an array

function* naturals() { let n = 1; while (true) yield n++; }

naturals()
  .filter((n) => n % 2 === 0)
  .map((n) => n * n)
  .take(5)
  .toArray();                  // [4, 16, 36, 64, 100]

The same chain on an array would build a full intermediate array at every step, and on an infinite source it would never finish. Iterator helpers (map, filter, take, drop, flatMap, reduce, toArray, some, every, find) pull one value at a time through the whole chain, and stop as soon as take is satisfied. They work on generators, Map and Set iterators, and anything wrapped with Iterator.from. The catch: an iterator is consumed once, so a helper chain cannot be replayed.

Dry run: pulling values one at a time through the chain

naturals() never generates 11 — once take(5) has its fifth value it stops pulling, and that stop propagates all the way back through map and filter to the generator itself. An array-based chain has no such brake: .filter().map() on an array would materialize a full intermediate array at every step, which is impossible on an infinite source in the first place.

Promise.try: one rule for sync and async failures

function load(input) {
  return Promise.try(() => JSON.parse(input))   // a sync throw becomes a rejection
    .then(save);
}

load("{ not json").catch(report);                // the error arrives here, not as a thrown exception

A function that is sometimes synchronous and sometimes returns a promise is a trap: a caller who writes .catch is not protected from the sync throw. The older fixes each have a flaw. Promise.resolve().then(fn) catches the error but delays running fn to a later microtask; new Promise((res) => res(fn())) is correct but noisy. Promise.try(fn, ...args) runs fn immediately and synchronously, and turns whatever happens — a return value, a promise, a throw — into a promise.

RegExp.escape: user text inside a pattern

const term = "file (1).txt";
new RegExp(term).test("file 1.txt");                 // true — the "." and ( ) were treated as syntax
new RegExp(RegExp.escape(term)).test("file 1.txt");  // false — matched literally

Building a regular expression from a search box without escaping is both a bug (a stray ( throws) and a security problem (a crafted pattern can backtrack catastrophically). Everyone used to paste the same replace(/[.*+?^${}()|[\]\\]/g, "\\$&") helper. The built-in version handles the edge cases that helper misses, including making the result safe to place next to other pattern text; note that it may write a leading letter or digit as a hex escape such as \x61, which looks odd and matches the same thing. Regular expressions also gained inline modifiers, so /^(?i:bearer) abc$/ is case-insensitive for just one group.

Error.isError, and why instanceof is not enough

const foreign = iframe.contentWindow.eval("new Error('x')");

foreign instanceof Error;      // false — it came from another realm's Error
Error.isError(foreign);        // true

Every iframe, worker and Node vm context has its own copy of Error, so instanceof fails for errors that crossed a boundary. Error.isError checks for the real internal error data, not the prototype chain, so it is true for genuine errors from any realm and false for a plain object that merely inherits from Error.prototype. It matters most in code that receives errors from elsewhere: a logging library, a test framework, a postMessage handler.

Set methods and a few smaller ones

const a = new Set([1, 2, 3]);
const b = new Set([3, 4]);

a.union(b);                // Set {1, 2, 3, 4}
a.intersection(b);         // Set {3}
a.difference(b);           // Set {1, 2}
a.isSubsetOf(b);           // false

await Array.fromAsync(asyncGenerator());       // an array of every yielded value, in order
new Float16Array([1.337])[0];                  // 1.3369140625 — half precision

Set methods replace a loop or a spread-and-filter, and they return new sets. Array.fromAsync awaits an async iterable one item at a time and gives you a normal array. Float16Array stores numbers in 16 bits, which is the point: graphics, GPU and machine-learning data where memory matters more than precision. Explicit resource management (using handle = open(), with Symbol.dispose) is covered with metaprogramming.

Temporal, the one that changes daily work

const today = Temporal.Now.plainDateISO();          // a date, no time, no zone
today.add({ days: 30 });

const meeting = Temporal.ZonedDateTime.from("2026-03-07T09:00[America/New_York]");
meeting.add({ days: 1 }).toString();
// "2026-03-08T09:00:00-04:00[America/New_York]" — still 9:00 on the wall, offset changed

Date mixes an instant, a local time and a formatting locale in one mutable object, which is where most date bugs come from. Temporal separates them: PlainDate for a calendar date, Instant for an exact moment, ZonedDateTime for a moment in a named time zone, Duration for an amount. Arithmetic respects daylight saving, and every object is immutable. Temporal reached the final stage of the standards process in March 2026, and Chrome and Firefox ship it; Safari had not shipped it in a stable release when this was written, so production code still uses the @js-temporal/polyfill package. The dates section shows why it exists.

Using new features without breaking old browsers

if (typeof Promise.try !== "function") {
  Promise.try = (fn, ...args) => new Promise((resolve) => resolve(fn(...args)));
}

• New syntax (using, import attributes, regex modifiers) is a parse error in an engine that does not know it, so it needs a transpiler for older targets.
• New built-ins (Promise.try, Set methods, iterator helpers) are just missing functions: feature-detect them, or load a polyfill such as core-js. Transpiling cannot add them.
• Decide by your data. Set your build's browser targets from your own analytics rather than a guess, and let that decide which of the above needs help.
• Node counts too. The same feature can be safe in the browser and missing in the Node version you deploy to; check both.