ES2024 is a specification, not your browser support policy

The right question about a new JavaScript feature is whether it works in the environments your product promises to support. The year printed on the specification cannot answer that. ES2024 made a useful annual record of language progress; it did not upgrade the browser on a customer’s phone or the runtime on a server.

Looking back from November 2026, the practical lesson is to adopt features individually. Use compatibility evidence such as Baseline, connect it to your own supported environments and verify the result there. This policy allows new language features without making every annual edition a compulsory migration project.

Approval and availability are different events

Ecma’s announcement dated 3 July 2024 says its General Assembly approved the fifteenth edition of ECMA-262 on 26 June. That distinction matters when recounting the history: the approval happened in June, while this particular public notice appeared in July.

Browser availability follows another timeline. MDN’s compatibility records for Object.groupBy() and Promise.withResolvers() date cross-browser availability to March 2024. Their current pages describe them as widely available. That current label must not be projected back onto June 2024 as though nothing had changed in the intervening time.

The TC39 process helps explain the sequence. Proposals progress through stages that require increasingly mature specification and implementation work. Stage 4 includes implementation and acceptance-test requirements before inclusion in the standard. Publication of an edition is therefore not a synchronized release date for all implementations. Conversely, an experimental implementation does not give a proposal the guarantees of a finished standard.

Small conveniences still need semantic review

Two ES2024 additions illustrate why adoption should happen at feature level. The 2024 specification defines Object.groupBy() for grouping iterable values and Promise.withResolvers() for obtaining a promise alongside its resolving functions. These can replace repetitive setup code. They solve different problems and have different failure consequences when absent.

For an illustrative reporting screen, grouping orders by status can make the intent easier to read than a hand-written accumulation loop. But changing the helper deserves a review of the returned object and the keys the application uses. Object.groupBy() returns a null-prototype object; code that assumes inherited object methods needs care. MDN documents that behavior on the method’s reference page.

For a boundary between an event-driven component and promise-based code, Promise.withResolvers() can avoid manually capturing resolving functions. It does not decide which events count as completion, arrange cancellation or prevent a pending operation from being forgotten. Those are still application decisions. Less setup code is a reason to consider the feature, not evidence that the surrounding asynchronous design is correct.

These are conceptual examples, not runnable snippets. No browser or runtime execution was performed for this article. A production change would need checks against the exact versions in the product’s support policy.

Baseline is evidence with a defined scope

Baseline’s overview describes a shared compatibility signal across its core browser set. That is useful when deciding whether an ordinary web feature is ready for broad use. It is not a declaration about every embedded browser, old device or server-side JavaScript runtime your application might encounter.

For a public booking page, a compatibility miss can stop a customer before checkout. For an internal tool on centrally managed browsers, the supported population may be much narrower. The same feature can be a sensible choice in the second product and require a fallback in the first. This is a difference in support commitments, not a judgment about which team writes more modern code.

Write down that commitment before adjusting build targets. Include the browser or runtime versions that matter, how exceptions are handled and who may retire an old environment. Product usage evidence can inform the choice where available. Do not invent a percentage of affected customers when you have no measurement.

A build target does not supply every missing API

Language syntax and runtime functionality need separate attention. Transforming new syntax into older syntax does not, by itself, create a missing built-in method. A build pipeline may be configured to add compatibility support, but that must be checked in the actual output and environment. The presence of an ES2024 target in configuration is not proof.

My suggested rule is to review a new built-in where it first becomes a dependency. If every supported environment has it, use it. If some do not, choose deliberately between a tested compatibility implementation, a local alternative or delaying adoption. A shared library needs to consider its consumers’ environments as well as the developer’s workstation.

Keep an owner and a removal condition for compatibility code. Otherwise a temporary fallback can become permanent maintenance after the original support requirement disappears. That cost should be visible when deciding whether a small reduction in repetitive code is worthwhile.

The reasonable case for an edition-wide rule

An organization may prefer a conservative annual language target because it is easy to explain and audit. That is defensible when consistency matters more than early access. It still needs an environment definition and an exception route; the edition number alone remains incomplete.

Accuracy also matters in feature lists. Top-level await already appears in the 2022 specification. Temporal is absent from the 2024 edition. Neither belongs in a list of features newly introduced by ES2024. Later documentation cannot retroactively change that snapshot.

For custom software, agree on the supported environments as part of delivery. Then new JavaScript features become small, reviewable choices tied to the people using the product. The annual standard remains useful context, while the support policy determines what you can ship.