Skip to content
AI & Software

Safari 27 Rewrote Its JavaScript Module Loader — Bringing Full Spec Compliance to Top-Level Await

WebKit says Safari 27 now has a fully standards-compliant ECMAScript module loader for top-level await. The team rebuilt the loader in native C++, translated the ECMAScript module algorithms directly into the engine, and validated the result with test262, Web Platform Tests, additional runtime cases, and generated module graphs.

JavaScript source code displayed in a code editor

01Safari 27 gives top-level await a new foundation

WebKit has rebuilt one of the less visible parts of Safari’s JavaScript engine, and the payoff lands directly in modern module code.

Safari 27 now ships a fully standards-compliant ECMAScript module loader for top-level `await`. Instead of extending the earlier loader, the WebKit team replaced it with a new implementation written in native C++ and mapped directly to the algorithms defined by the ECMAScript specification.

For developers, the result is simple: top-level `await` can now be used in Safari 27 with the same module semantics expected across modern JavaScript environments.

The work is deeper than a small compatibility patch. It changes the machinery that loads, links, and evaluates ES modules, giving Safari a cleaner base for asynchronous module execution going forward.

02Top-level await changes how a module graph moves

Top-level `await` looks small at the syntax level.

A module can pause while it waits for a Promise without wrapping that work inside an async function. The interesting behavior happens in the dependency graph around it.

When one module pauses at top level, modules that depend on it also wait for its evaluation to finish. Other sibling modules that do not depend on that path can continue running. The browser therefore has to keep track of dependencies, execution order, and asynchronous completion across the whole graph.

That is why module-loader design matters so much here. The feature is not only about parsing `await`. The runtime has to coordinate the surrounding modules correctly while preserving the semantics defined by the ECMAScript standard.

Safari 27’s rewrite puts that coordination directly into the engine’s standards-based module machinery.

03WebKit translated the specification into native C++

The rewrite began in January 2026.

WebKit engineers first mapped the ECMAScript module-loading operations and the way those operations call one another. From there, they implemented the lower-level pieces first and worked upward through the module state machine.

The new loader is native C++, replacing the earlier self-hosted JavaScript approach.

WebKit says native code is a better fit for this part of the engine because the module loader is infrastructure rather than a hot user-code path. It can be compiled ahead of time and behave more predictably inside JavaScriptCore.

The team also used the ECMAScript specification itself as the design source, giving the implementation a cleaner standards-based foundation.

04The rewrite went through several layers of testing

A foundational rewrite needs more than a few hand-written examples.

WebKit tested the new loader against the JavaScript test262 suite and Web Platform Tests, and also adapted cases contributed by engineers working on Bun, which uses JavaScriptCore.

The team added another layer: a fuzzer that generates complex module graphs containing different combinations of imports and top-level `await`.

Those graphs were run through JavaScriptCore and compared with other JavaScript engines. WebKit says the tested outputs matched byte-for-byte, giving the team a way to validate observable execution behavior across many generated cases.

By the time the rewrite was merged, the module-related test262 coverage was passing and the team had been using Safari builds with the new loader in its own daily development workflow.

Side-by-side comparison of two JavaScript source files
Illustrative JavaScript source comparison. Tommy Kronkvist / Wikimedia Commons, CC BY-SA 4.0. TUF branding/watermark required for publication.

05This rewrite fits Safari 27’s larger quality push

The module-loader work is part of a wider Safari 27 theme.

At WWDC26, Apple’s WebKit team described a release cycle focused heavily on engine quality, interoperability, and foundational rewrites. Safari 27 beta arrived with dozens of new web-platform features and hundreds of fixes, while the broader year of work included more than a thousand engine improvements.

That strategy is visible in the top-level `await` project. Rather than treating module behavior as an isolated surface feature, WebKit rebuilt the underlying system that controls how modules are evaluated.

The same approach appears elsewhere in Safari 27, where the team has been revisiting engine foundations and aligning them more directly with current web standards.

For web developers, that kind of work is easy to miss in a feature list. It becomes much more visible when a modern JavaScript pattern can be used without special handling for one browser.

Official Video

What’s new in WebKit for Safari 27

Apple Developer

06ES modules become easier to use as a common baseline

Top-level `await` has become a useful tool for modules that need asynchronous setup before their exports are ready.

A module can load configuration, initialize a resource, or wait for another asynchronous operation and then expose a ready-to-use interface to the rest of the application. Importing modules can stay declarative instead of pushing initialization logic into a separate bootstrap layer.

With Safari 27’s loader rewrite, WebKit says developers can rely on top-level `await` and ES modules as a production foundation once Safari 27 ships.

That has a practical effect on cross-browser code. When the same module semantics are available across major engines, application code can stay closer to the standard instead of carrying browser-specific execution paths.

For teams building module-heavy applications, the value is less about one syntax feature and more about having a shared baseline for how the entire graph behaves.

07Developers can test it now

The new loader is already available for testing.

WebKit points developers to Safari Technology Preview 251 and the Safari 27 beta. That gives teams a chance to run existing module-heavy applications against the new implementation before the final Safari 27 release.

The official WebKit article also includes a compact example that dynamically imports the same module several times while that module pauses on a top-level `await`. Under the new loader, the imports complete in the expected order and expose their exports after evaluation is ready.

For teams maintaining JavaScript frameworks, build tools, or applications with complex dependency graphs, this is a useful release to test early.

The rewrite reaches below the application surface, so the best validation comes from real module graphs rather than isolated syntax checks.

08The Upgrade Feeling

This is the kind of browser update that looks small from the outside and turns out to be architectural.

Safari 27 did not just add another JavaScript feature flag. WebKit rebuilt the module loader in native C++, aligned it directly with the ECMAScript algorithms, and validated the result across standards suites and generated dependency graphs.

That gives top-level `await` a stronger foundation, but the bigger win is broader: ES modules now sit on cleaner machinery inside Safari.

For web developers, that means one less reason to treat modern module code as browser-specific territory.

Get smarter updates

Straight to your inbox. No spam. Only useful tech.

Discover more from That Upgrade Feeling

Subscribe now to keep reading and get access to the full archive.

Continue reading

Discover more from That Upgrade Feeling

Subscribe now to keep reading and get access to the full archive.

Continue reading