The last engine catches up
Apple's WebKit team shipped Safari Technology Preview 250 on August 13, 2026, and buried in the release notes is a change JavaScript developers have been waiting years for: full support for the using and await using declarations, along with Symbol.dispose, DisposableStack and AsyncDisposableStack. Safari Technology Preview is Apple's early-access channel for testing upcoming WebKit features before they reach the shipping Safari browser, so this support is not yet in stable Safari, but it means all three major JavaScript engines now have working implementations of the feature, at least in their preview or current builds: V8 (which powers Chrome and Node.js), SpiderMonkey (Firefox) and now WebKit (Safari).
What the feature actually does
The feature comes from a Technical Committee 39 (TC39) proposal called Explicit Resource Management. TC39 is the standards committee that governs the ECMAScript specification, the formal name for the JavaScript language. The proposal reached Stage 4, the committee's final stage before a feature is folded into the official specification, in 2025.
In practice, using solves a problem JavaScript has never had a clean built-in answer for: making sure something gets cleaned up when a block of code finishes, whether it finishes normally, returns early, or throws an error. Database connections, file handles, timers and locks all need this kind of guaranteed cleanup. Before this proposal, developers reached for try/finally blocks by hand, or a cleanup library, every time.
With using, any object that defines a [Symbol.dispose]() method gets disposed of automatically the moment execution leaves the block it was declared in:
{
using file = openFile("data.txt");
// work with file
} // file.[Symbol.dispose]() runs here, automatically
For cleanup that itself needs to be asynchronous, such as closing a network connection, await using does the same thing but calls [Symbol.asyncDispose]() and awaits the result before continuing:
{
await using connection = await openConnection();
// work with connection
} // connection.[Symbol.asyncDispose]() is awaited here
When a block declares more than one using resource, they are disposed of in the reverse of the order they were declared, mirroring how stack-based cleanup works in other languages. If disposal itself throws an error while another error is already in flight, JavaScript now aggregates both into a SuppressedError rather than silently dropping one of them. DisposableStack and AsyncDisposableStack, also included in this release, give developers a way to collect multiple disposable resources programmatically and dispose of them together, useful when the set of resources to clean up is not known upfront as a fixed list of variables.
Why Safari was the holdout
V8 shipped Explicit Resource Management in Chromium 134, putting it in Chrome and Node.js. Firefox's SpiderMonkey engine landed its own implementation over the following months. Safari was the outlier, and the gap mattered in practice, according to TechTimes: TypeScript developers have been able to write using in their source code for more than two years, but TypeScript's compiler had to transpile it away into older, more verbose equivalent code for any project that needed to run in Safari, since the browser had no native support to compile down to. The Multilingual Development Metadata Repository tracking service caniuse.com still lists the feature as not meeting the "Baseline" bar, the industry benchmark for a feature working in all major widely used browsers, because Safari's stable release does not have it yet.
Safari Technology Preview 250 was not a single-feature release. The same build also added Iterator.zip() and Iterator.zipKeyed() from a separate Joint Iteration proposal, initial support for uploading ReadableStream request bodies through fetch(), and new CSS properties including ruby-overhang and text-decoration-inset, according to WebKit's own release notes.
What it means for developers
This is not yet a green light to ship using straight to production for a Safari-facing website; Technology Preview builds exist specifically so developers can test upcoming behavior before it reaches the stable browser millions of people actually use, and Apple has not announced when this will land in a numbered Safari release. What has changed is the trajectory: with a working WebKit implementation now in a public preview build, using is on a clear path toward becoming usable without a transpiler across the entire browser landscape, not just in Chrome, Firefox and Node.js. Developers building libraries or frameworks that manage resources such as database clients, file streams or UI subscriptions have a concrete signal that native support is close enough to start planning around, even if today's production code targeting Safari still needs TypeScript's transpiled fallback or a manual try/finally block.
