JavaScript's New Superpower: Explicit Resource Management

This is why TC39 needs to work on fundamental language features like protocols. In Rust, you can define a new trait and impl it for existing types. This still has flaws (orphan rule prevents issues but causes bloat) but it would definitely be easier in a dynamic language with unique symbol capabilies to still come up with something.

Isn't this typically solved with polyfills in the JavaScript world?

    import { SomeStreamClass as SomeStreamClass_ } from "some/library"
    export class SomeStreamClass extends SomeStreamClass_ {
      [someSymbol] (...) { ... }
      ...
    }

That's because the author of the proposal is from Microsoft and has repeatedly shot down counter-suggestions that made the syntax look different from C#.

https://github.com/tc39/proposal-explicit-resource-managemen...

https://github.com/tc39/proposal-explicit-resource-managemen...

https://github.com/tc39/proposal-explicit-resource-managemen...

https://github.com/tc39/proposal-explicit-resource-managemen...

It's basically lifted from C#'s, the original proposal makes no secret of it and cites all of Python's context managers, Java's try with resources, C#'s using statements, and C#'s using declarations. And `using` being the keyword and `dispose` the hook method is a pretty big hint.

The spec just says that when a block "completes" its execution, however that happens (normal completion, an exception, a break/continue statement, etc.) the disposal must run. This is the same for "using" as it is for "try/finally".

When a process is forcibly terminated, the behavior is inherently outside the scope of the ECMAScript specification, because at that point the interpreter cannot take any further actions.

So what happens depends on what kind of object you're talking about. The example in the article is talking about a "stream" from the web platform streams spec. A stream, in this sense, is a JS object that only exists within a JS interpreter. If the JS interpreter goes away, then it's meaningless to ask whether the lock is locked or unlocked, because the lock no longer exists.

If you were talking about some kind of OS-allocated resource (e.g. allocated memory or file descriptors), then there is generally some kind of OS-provided cleanup when a process terminates, no matter how the termination happens, even if the process itself takes no action. But of course the details are platform-specific.

Destructors require deterministic cleanup, which advanced GCs can't do (and really don't want to either from an efficiency perspective). Languages with advanced GCs have "finalizers" called during collection which are thus extremely unreliable (and full of subtle footguns), and are normally only used as a last resort solution for native resources (FFI wrappers).

Hence many either had or ended up growing means of lexical (scope-based) resource cleanup whether,

- HoF-based (smalltalk, haskell, ruby)

- dedicated scope / value hook (python[1], C#, Java)

- callback registration (go, swift)

[1]: Python originally used destructors thanks to a refcounting GC, but the combination of alternate non-refcounted implementations, refcount cycles, and resources like locks not having guards (and not wanting to add those with no clear utility) led to the introduction of context managers

  def synchronize
    lock
    begin
      yield
    ensure
      unlock
    end
  end

  lock.synchronize {
    # protected code here
  }

For garbage collected languages destructors cannot be called synchronously in most cases because the VM must make sure that the object is inaccessible first. So it will not work very deterministically, and also will expose the JS VM internals. For that JS already has WeakRef and FinalizationRegistry.

https://waspdev.com/articles/2025-04-09/features-that-every-... https://waspdev.com/articles/2025-04-09/features-that-every-...

But even Mozilla doesn't recommend to use them because they're quite unpredictable and might work differently in different engines.

Destructors I other languages are typically used for when the object is garbage collected. That has a whole bunch of associated issues, which is why the pattern is often avoided these days.

The dispose methods on the other hand are called when the variable goes out of scope, which is much more predictable. You can rely on for example a file being closed ot a lock released before your method returns.

JavaScript is already explicit about what is synchronous versus asynchronous everywhere else, and this is no exception. Your method needs to wait for disposing to complete, so if disposing is asynchronous, your method must be asynchronous as well. It does get a bit annoying though that you end up with a double await, as in `await using a = await b()` if you're not used to that syntax.

As for using symbols - that's the same as other functionality added over time, such as iterator. It gives a nice way for the support to be added in a backwards-compatible way. And it's mostly only library authors dealing with the symbols - a typical app developer never has to touch it directly.

Because this approach also works for stuff that is not a class instance.

There is no such thing as an anonymous property in JavaScript. Your question doesn't make sense. What else could this possibly be?

Because javascript is uncivilized.

That's the neat part, you don't. 90% percent of webdev is "upgrading" things in ways nobody asked for or appreciates because it's just taken for granted that your codebase will grow mold or something if it isn't stirred often enough and the other 10% of the work is fixing legitimate problems resulting from the first 90%. Of course, no probability is ever actually 1.0 so there will be rare occasions that you need to understand something that ChatGP-err, sorry my bad, i meant to say "something that you" wrote more than a year ago you suggest to your boss that this bug should be preserved until next time there's a new hire because it would make a great "jumping-on" point and until then the users will still be able to get work done by using the recommended work-around, whic his installing windows XP Pirate Edition onto a VM and using IE6 to get into the legacy-portal that somehow inexplicably still exists 20 years after the corporate merger that was supposed to make it obsolete.

For starters, your code is so full of serious syntax errors that in some places it's not even close to valid JavaScript. This is my best guess reconstruction:

    (async (e) => {
      await doSomething()
      while (!done) {
        ({ done, value }) = await reader.read()
      }

      promise
        .then(goodA, badA)
        .then(goodB, badB)
        .catch(err => console.log(err))
        .finally(() => {
          using stack = new DisposableStack()
          stack.defer(() => console.log('done.'))
        })
    })()

But more importantly, this isn't even close to anything a reasonable JS dev would ever write.

1. It's not typical to mix await and while(!done), I can't imagine what library actually needs this. You usually use one or the other, and it's almost always just await:

    await doSomething()
    const value = await readFully(reader)

2. If you're already inside an Async IIFE, you don't need promise chains. Just await the stuff as needed, unless promise chains make the code shorter and cleaner, e.g.:

    const json = await fetch(url).then(r => r.json())

3. Well designed JS libraries don't usually stack promise handlers like the {good,bad}{A,B} functions you implied. You usually just write code and have a top level exception handler:

    using stack = new DisposableStack()
    stack.defer(() => console.log('done.'))
    try {
      const goodA = await promise
      const goodB = await goodA
      const goodC = await goodB
      return goodC
    }
    catch(e) {
      myLogErr(e)
    }
    // finally isn't needed, that's the whole point of DisposableStack

4. We don't usually need AIIFEs anymore, so the outer layer can just go away.

To embed code on HN, add 2 or more spaces at the beginning of each line:

  async (() => (e) {
  try { await doSomething();
        while (!done) { ({ done, value } = await reader.read()); }
        promise
        .then(goodA, badA)
        .then(goodB, badB)
        .catch((err) => { console.error(err); }
  catch { } 
  finally { using stack = new DisposableStack();
  stack.defer(() => console.log("done.")); }
  });

(indentation preserved as posted by OP – I don't understand how somebody can code like this either :-)

By programming in the language for a living and being familiar with the semantics of the language's keywords -- likely the same way anyone else understands their preferred language?

People write Haskell for a living, after all.

Indenting helps.

LLMs will do only this and you'll love it.

Maybe not love it, but you really won't have a choice.

I mean we're talking about a language community where someone created a package to tell if a variable is a number... and it gets used *a lot*.

That JavaScript has progressed so much in some ways and yet is still missing basic things like parameter types is crazy to me.

The error was probably trying to write a generic `using`. In my experience languages which use higher order functions or macros for scope cleanup tend to build high-level utilities directly onto the lowest level features, it can be a bit repetitive but usually not too bad.

So in this case, rather than a generic `using` built on the even more generic `try/except` you should probably have built a `withFile` callback. It's a bit more repetitive, but because you know exactly what you're working with it's a lot less error prone, and you don't need to hope there's a ready made protocol.

It also provides the opportunity of upgrading the entire thing e.g. because `withFile` would be specialised for file interaction it would be able to wrap all file operations as promise-based methods instead of having to mix promises and legacy callbacks.

It's similar, but more inspired by C#'s "using declaration", an evolution of the using blocks, which are the C# version of try-with-resource: `using` declarations don't introduce their own block / scope.

The original proposal references all of Python's context manager, Java's try-with-resource, and C#'s using statement and declaration: https://github.com/tc39/proposal-explicit-resource-managemen...

Yeah, as someone else has pointed out it's C# inspired, this is a C# example:

    public void AMethod() {
        //some code
        using var stream = thing.GetStream();
        //some other code
        var x = thing.ReadToEnd();
        //file will be automatically disposed as this is the last time file is used
        //some more code not using file
    } //any error means file will be disposed if initialized

You can still do the wrap if you need more fine grained control, or do anything else in the finally.

You can even nest them like this:

    using var conn = new SqlConnection(connString);
    using var cmd = new SqlCommand(cmd);
    conn.Open();
    cmd.ExecuteSql();

Edit: hadn't read the whole article, the javascript version is pretty good!

What you describe is already the status quo today. This proposal is still a big improvement as it makes resource management less error prone when you're aware to use it and _standardizes the mechanism through the symbol_. This enables tooling to lint for the situations you're describing based on type information.

Here’s some relevant discussion about some of the footguns:

https://github.com/typescript-eslint/typescript-eslint/issue...

https://github.com/tc39/proposal-explicit-resource-managemen...

I imagine there will eventually be lint rules for this somewhere and many of those using such a modern feature are likely to be using static analysis via eslint to help mitigate the risks here, but until it’s more established and understood and lint rules are fleshed out and widely adopted, there is risk here for sure.

https://github.com/typescript-eslint/typescript-eslint/issue...

To me it seems a bit like popular lint libraries just going ahead and adding the rule would make a big difference here

There is pretty strong precedent for this design over in .NET land - if it was awful or notably inferior to `defer` I'm sure the Chrome engineering team would have taken notice.

Exactly this. No idea why you were downvoted.

The problem they are trying to solve is that the programmer could forget to wrap an object creation with try. But their solution is just kicking the can down the road, because now the programmer could forget to write "using"!

I was thinking that a much better solution would be to simply add a no-op default implementation of dispose(), and call it whenever any object hits end-of-scope with refcount=1, and drop the "using" keyword entirely, since that way programmers couldn't forget to write "using". But then I remembered that JavaScript doesn't have refcounts, and we can't assume that function calls to which the object has been passed have not kept references to it, expecting it to still exist in its undisposed state later.

OTOH, if there really is no "nice" solution to detecting this kind of "escape", it means that, under the new system, writing "using" must be dangerous -- it can lead to dispose() being called when some function call stored a reference to the object somewhere, expecting it to still exist in its undisposed state later.

> JS: drop but we couldn't occupy a possibly taken name, Symbol for the win!

You're about a decade late to the party?

That is the entire point of symbols and "well known symbols", and why they were introduced back in ES6.

nah, Symbol has been traits for javascript for quite a while eg. Symbol.iterator

It's the "dispose" part where the new name is decided.

Yes you are missing something. You are not supposed to call these methods, they are for the runtime.

more specifically, javascript will call the [Symbol.dispose] when it detects you are exiting the scope of a "using" declaration.

JS has used "well-known symbols"[1] to allow extending / overriding the functionality of objects for about 10 years. For example, an object is an iterable if it has a `[Symbol.iterator]` property. Symbols are valid object keys; they are not just string aliases.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> create a new global object named "Resource" which has the needed method prototypes that can be overwritten.

those methods could conflict with existing methods already used in other ways if you’d want to make an existing class a subclass of Resource.

> identified not with a standard name (like Object.constructor() or Object.__proto__)

__proto__ was a terrible mistake. Google “prototype pollution”; there are too many examples to link. In a duck-typed language where the main mechanism for data deserialization is JSON.parse(), you can’t trust the value of any plain string key.

> To make a "resource", you'll tack on a new magical method to your POJO, identified not with a standard name [...] nothing to do with Symbol's core purpose of creating unique identifiers.

The core purpose and original reason why Symbol was introduced in JS is the ability to create non-conflicting but well known / standard names, because the language had originally reserved no namespace for such and thus there was no way to know any name would be available (and not already monkey patched onto existing types, including native types).

> Is there another example of an arbitrary method name being called by a keyword? It's not a function parameter like async/await uses to return a Promise, it's just a random method tacked on to an Object using a Symbol to define the name of it. Weird!

`Symbol.iterator` called by `for...of` is literally the original use case for symbols.

> I'd think the proper JavaScript way to do this would be to either make a new object specific modifier keyword like the way getters and setters work, or to create a new global object named "Resource" which has the needed method prototypes that can be overwritten.

Genuinely: what are you talking about.

I hadn't considered how blessed I was to have __enter__ / __exit__ in Python for context managers and the more general Protocol concept that can be used for anything because lordy that definition looks ugly as sin. Even Perl looks on in horror of the sins JS has committed.

What do you mean by that? Is `drop` a language construct in another language?

Drop?

They're just adopting the same syntax that C# has used for a long time

It depends on what language the Javascript engine is implemented in. For v8 that's c++ yeah. I would agree with Google being a super villain nowadays, but others use c++ too so I would think it's unfair to call it supervillain language...